From: Matthieu Moy <Matthieu.Moy@grenoble-inp•fr>
To: "Michael S. Tsirkin" <mst@redhat•com>
Cc: Christian Couder <christian.couder@gmail•com>,
Junio C Hamano <gitster@pobox•com>, git <git@vger•kernel.org>
Subject: Re: git interpret-trailers with multiple keys
Date: Mon, 11 Apr 2016 09:09:48 +0200 [thread overview]
Message-ID: <vpqegac7hab.fsf@anie.imag.fr> (raw)
In-Reply-To: <20160410203556-mutt-send-email-mst@redhat.com> (Michael S. Tsirkin's message of "Sun, 10 Apr 2016 20:43:01 +0300")
"Michael S. Tsirkin" <mst@redhat•com> writes:
> On Sun, Apr 10, 2016 at 06:57:53PM +0200, Christian Couder wrote:
>> What I meant is that we could create new options called maybe
>> trailer.autocommands and trailer.<token>.autocommands that default to
>> 'true' and if 'false' the command would not be run automatically and
>> the corresponding trailer would not be added.
>
> I don't think it has to do with commands.
> For example, if we add "value" it should behave the same.
>
> So I think a better name is "ifnotlisted", with values "add"
> and "donothing".
Having a negation in the variable name feels wrong. When the token is
listed on the command-line and ifnotlisted=donothing, I have to apply a
double-negation to guess what would happen (=> "if listed then do
something").
I agree that having such variable would be a good thing. It would solve
your issue (i.e. "How to I configure a token for quick use from the
command-line without applying it unconditionally"), and allow full
backward compatibility.
I'd call the option "apply" or perhaps "run", with values 1/true/always
= default = current behavior, or "auto" = "apply when asked from the
command-line". I'm wondering whether other values could make sense (not
to implement it right now, but to keep the design open to further
extensions): perhaps apply=ifauthor could mean "apply this trailer to
patches I'm the author of" for example.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2016-04-11 7:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 16:12 git interpret-trailers with multiple keys Michael S. Tsirkin
2016-04-06 16:58 ` Matthieu Moy
2016-04-06 17:16 ` Michael S. Tsirkin
2016-04-06 17:42 ` Junio C Hamano
2016-04-06 19:30 ` Michael S. Tsirkin
2016-04-07 2:28 ` Christian Couder
2016-04-10 15:32 ` Michael S. Tsirkin
2016-04-10 16:57 ` Christian Couder
2016-04-10 17:06 ` Michael S. Tsirkin
2016-04-10 17:43 ` Michael S. Tsirkin
2016-04-11 7:09 ` Matthieu Moy [this message]
2016-04-11 7:24 ` Michael S. Tsirkin
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=vpqegac7hab.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp$(echo .)fr \
--cc=christian.couder@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=mst@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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