Re: [PATCH v5 2/4] git-cherry-pick: Add keep-redundant-commits option

[Clemens Buchacher <drizzd@aon.at>]

On Tue, Apr 17, 2012 at 08:42:52AM -0700, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> 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?