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

[Junio C Hamano <gitster@pobox.com>]

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.

So "consistency" between the two would actually be a mistake that we may
want to "break", I would think.