Guido Günther <a...@sigxcpu.org> writes:
> Without this when maintaining stable branches it's easy to forget to use
> -x to track where a patch was cherry-picked from.
> ---
> Documentation/config.txt | 4 ++++
> Documentation/git-cherry-pick.txt | 8 ++++++++
> builtin/revert.c | 14 +++++++++++++-
> 3 files changed, 25 insertions(+), 1 deletion(-)
Hmph. Does this round address the issues raised in the previous
discussion in any way?
How does it affect people's existing scripts that use cherry-pick
and rely on it not doing the unwanted -x thing if such a
configuration variable is introduced as the first step in the
series, without even giving them to override the configured default
from the command line?
For that matter, I do not think a new override option from the
command line is a great solution, as that approach forces people's
existing script to be adjusted.
I personally found the way Jonathan explained why "git backport"
alias is the best solution (not just a usable workaround) very
compelling, especially his point (3):
(3) The caller explicitly specifies their intent by running "git
backport". It doesn't affect unrelated uses of cherry-pick on
other branches.
I do not even mind throwing something like this:
#!/bin/sh
# "git backport" - cherry-pick with -x always on.
exec git cherry-pick -x "$@"
in contrib/ somewhere, which feels like a far more appropriate
solution to your "easy to forget" problem, at least to me.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
