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.
Because --no-ff could be used when the GIT_COMMITTER_* and GIT_AUTHOR_* env
variable should be respected? Or because we should check if one of these
env variable is set and, if that is the case, we should not fast forward?
I wish it could be the former, at least in the long run; after all git
merge fast-forwards by default, and it doesn't adjust its behavior if
GIT_COMMITTER_* is passed.
Anyway, your plan of starting with --ff and changing the default to
--no-ff later seems fine. Maybe you can add --no-ff now already, though
it would be a no-op.
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.
Yeah, but let's change the default later please.
Sure.
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