Re: [RFC/PATCH 5/6] revert: add --ff option to allow fast forward when cherry-picking

[Paolo Bonzini <bonzini@gnu.org>]

On 02/01/2010 01:43 PM, Christian Couder wrote:
> Maybe it could be the default, but in this case it should be made
> compatible with -n option (and perhaps other options) for backward
> compatibility, and this would probably need more involved changes.

A better objection is that GIT_COMMITTER_* is respected by |git 
cherry-pick" but not by "git cherry-pick --ff", and that even without 
setting the variables, "git cherry-pick" will pick a new commit date but 
"git cherry-pick --ff" wouldn't.  The latter, I think is the only 
difference that is worth pondering further.

My impression is that a user would never have any problem with 
fast-forwarding.  For scripts probably the same is true (the typical 
scenario for scripts is probably very similar to what "git rebase -i" 
does), but it can still be a potential backwards-incompatibility in case 
the script is *expecting* cherry-picking to generate a new SHA1.  How 
broken can we consider this expectation?


That said, to reply to your question, of course -n would disable it, and 
so would -x, -s and possibly -e.  But then, the same applies to --ff: 
your patch forbids "-n --ff", but -x, -s and -e would need the same 
treatment.

Note that "-e --ff" would error out; however if --ff would be the 
default, "-e" would probably choose between fast-forward and 
non-fast-forward depending on whether the commit message was edited.

Paolo