From: Jonathan Nieder <jrnieder@gmail.com>
To: "Guido Günther" <agx@sigxcpu.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] revert.c: Allow to specify -x via git-config
Date: Tue, 18 Feb 2014 09:49:13 -0800 [thread overview]
Message-ID: <20140218174913.GB7855@google.com> (raw)
In-Reply-To: <20140218065620.GA3448@bogon.m.sigxcpu.org>
Hi,
Guido Günther wrote:
> Without this when maintaining stable branches it's easy to forget to use
> -x to track where a patch was cherry-picked from.
[...]
> --- a/Documentation/git-cherry-pick.txt
> +++ b/Documentation/git-cherry-pick.txt
> @@ -215,6 +215,14 @@ the working tree.
> spending extra time to avoid mistakes based on incorrectly matching
> context lines.
>
> +CONFIGURATION
> +-------------
> +
> +See linkgit:git-config[1] for core variables.
> +
> +cherrypick.record-origin::
> + Default for the `-x` option. Defaults to `false`.
I'm not convinced this is a good idea. Even if I always want -x when
cherry-picking to stable, isn't this going to add the extra clutter
line when I cherry-pick on other branches? It's especially worrying
because there would be no way to override the configuration with a
flag on the command line. ("-r" which used to do that is now a
no-op.)
I would be more easily convinced by a '[branch "foo"]
recordcherrypickorigins' option that makes cherry-pick default to '-x'
when and only when on the "foo" branch.
Can you say more about the context? Why is it important to record the
original commit id? Is it a matter of keeping a reminder of the
commits' similarity (which cherry-pick without '-x' does ok by reusing
the same message) or are people reviewing the change downstream going
to be judging the change based on the recorded upstream commit id?
(Like linux's stable-<version> branches --- but those have other
requirements so I don't think this configuration would work as is
there.)
[...]
> +++ b/builtin/revert.c
> @@ -196,6 +196,15 @@ int cmd_revert(int argc, const char **argv, const char *prefix)
[...]
> + if (!strcmp(var, "cherrypick.record-origin"))
> + opts->record_origin = git_config_bool (var, value);
More nitpicky: git uses camelCase, not dash-delimited, for multiword
configuration items. The config parsing machinery normalizes to
lowercase, so this would then be "cherrypick.recordorigin".
Hope that helps,
Jonathan
next prev parent reply other threads:[~2014-02-18 17:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 6:56 [PATCH] revert.c: Allow to specify -x via git-config Guido Günther
2014-02-18 9:11 ` John Keeping
2014-02-18 17:49 ` Jonathan Nieder [this message]
2014-02-18 18:38 ` brian m. carlson
2014-02-18 19:20 ` Jonathan Nieder
2014-02-18 21:27 ` [PATCH v2 0/3] Allow to configure cherry-pick's record origin Guido Günther
2014-02-18 21:27 ` [PATCH v2 1/3] revert.c: Allow to specify -x via git-config Guido Günther
2014-02-19 19:57 ` Junio C Hamano
2014-02-18 21:27 ` [PATCH v2 2/3] revert.c: Add --record-origin Guido Günther
2014-02-18 21:27 ` [PATCH v2 3/3] revert.c Allow to override cherrypick.recordOrigin Guido Günther
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140218174913.GB7855@google.com \
--to=jrnieder@gmail.com \
--cc=agx@sigxcpu.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.