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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).