Re: [PATCH v2 1/3] revert.c: Allow to specify -x via git-config

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 19, 2014, 19:57 UTC
Message-ID: <xmqqy51698pa.fsf@gitster.dls.corp.google.com>
In-Reply-To: <85b9fa68b1a5542817489ddbe186cbb7600599b0.1392758057.git.agx@sigxcpu.org>

Guido Günther <agx@sigxcpu.org> writes:

Show 7 quoted lines

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