On Tue, Apr 17, 2012 at 11:37:23PM +0200, Clemens Buchacher wrote: > 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? > Well, I've got the comment in the code indicating what were doing, but sure, I can be more vebose in the commit message about whats going on. I can probably rename the empty variable to indicate its meaning a bit more clearly and make that code more readable. 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