Guido Günther <> 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:

        # "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
More majordomo info at

Reply via email to