On Wed, Apr 11, 2012 at 11:50:29AM -0700, Junio C Hamano wrote: > Neil Horman <nhorman@xxxxxxxxxxxxx> writes: > > >> But that cannot be correct, without --continue [*1*], i.e. > >> > >> $ git cherry-pick --allow-empty --continue > >> > >> no? I didn't check, but if the command without --continue in the above > >> sequence does not error out, I think it is a bug. > >> > > No, it errors out. I'm sorry to have confused you. The only point that I was > > trying to make here is that, when running git cherry-pick, its seems awkward to > > a user to get advice indicating that git commit --allow-empty should be run. > > I was only saying that "git cherry-pick --allow-empty" is a *bad* > suggestion because it does *not* work and errors out, and you seem to > agree with me on that point. I also said I am OK if the suggestion for > this case were to run "git cherry-pick --continue". > > But you sound like you are disagreeing with me; I am not sure where you > found what I said not agreeable. So I am not sure what to say at this > point. > I'm sorry, I think I see where our mutual confusion is. git cherry-pick --allow-empty _does_ error out on its own. The advice that I rewrote was meant to imply that the cherry-pick command should have been rerun with the --allow-empty option, i.e.: git cherry-pick --allow-empty <commit> I can see however, looking at from what I think was your point of view, how the advice would have been bad, because taken strictly as given, it would fail. Its all moot however, I've reverted the advice in my tree here. As soon as I complete testing of the optimization/rewites to git_run_commit and is_original_commit_empty, I'll have another set for review. Regards Neil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html