On Tue, Apr 17, 2012 at 08:42:52AM -0700, Junio C Hamano wrote: > 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. Yeah, that makes sense. > So "consistency" between the two would actually be a mistake that we may > want to "break", I would think. Agreed. But we should document the change in the commit message and maybe add a comment, because it is really strange to read if (!empty && index_empty) return "it's all good" if (empty) return "oh noes!" without an explanation as to why empty and index_empty are so different. Neil, what do you 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