From: Clemens Buchacher Date: Tue, 17 Apr 2012 21:37:23 GMT Subject: Re: [PATCH v5 2/4] git-cherry-pick: Add keep-redundant-commits option Message-ID: <20120417213723.GA19908@ecki> In-Reply-To: <7v3982pdoj.fsf@alter.siamese.dyndns.org> On Tue, Apr 17, 2012 at 08:42:52AM -0700, Junio C Hamano wrote: > Clemens Buchacher 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 fails. But with your changes, git > > cherry-pick will succeed and do nothing, > > while before it would have failed exactly like git cherry-pick > > . > > > > 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?