Clemens Buchacher <drizzd@xxxxxx> writes: > On Mon, Apr 16, 2012 at 11:38:27AM -0400, Neil Horman wrote: > ... > Except that the outcome is not the same. With and without your changes, > git cherry-pick <empty-commit> fails. But with your changes, git > cherry-pick <commit-will-become-empty> will succeed and do nothing, > while before it would have failed exactly like git cherry-pick > <empty-commit>. > > So I am not arguing whether failing or skipping is the better default > behavior. But the legacy behavior is consistent between the empty-commit > and commit-will-become-empty cases. Is that particular "consistency" a good one, though? If you had an empty commit in the original range, it is a lot more likely that it was an error that you would want to know about. You may be the kind of person who value an empty commit in your history, using it as some kind of a mark in the history, and in that case you would want to know that it is being discarded. On the other hand, if a commit that did something in the original context turns out to be unnecessary in the replayed context, that is not something you would ever want to keep in the replayed context, and erroring out and forcing you to say "yeah, I admit I do not want it" would just be annoying. So "consistency" between the two would actually be a mistake that we may want to "break", I would think. -- 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