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 -- 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