From: Michael Hendricks <michael@ndrix.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] format-patch: add arbitrary email headers
Date: Thu, 26 Mar 2009 10:42:12 -0600 [thread overview]
Message-ID: <20090326164212.GF29569@ginosko.ndrix.org> (raw)
In-Reply-To: <7v3ad11kqh.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 25, 2009 at 12:11:02PM -0700, Junio C Hamano wrote:
> Michael Hendricks <michael@ndrix.org> writes:
>
> > format-patch supports the format.headers configuration for adding
> > arbitrary email headers to the patches it outputs. This patch adds
> > support for a --header argument which makes the same feature available
> > from the command line. This is useful when the content of custom
> > email headers must change from branch to branch.
>
> How should this interact with the configuration variable?
>
> Typically we allow command line options to override the matching config
> variable, so that people can say "here are the settings I ordinarily use"
> in the config file, and say "but I do not want the usual values to take
> effect for this particular invocation; please use these _instead_" with
> command line options.
>
> Note that the above question is "how should this interact"; not "how does
> this interact". I can see you chose to make this cumulative in your patch
> and the documentaiton.
>
> I am asking if that is what the users want, overriding is preferred, or
> perhaps another option to clear extra headers (say, "--no-extra-headers")
> is necessary to allow both.
In all the cases where I use custom headers on patch emails, I want
the command line headers to be cumulative with the config headers. I
only configure headers which are constant (such as "X-Project:
project-name"). The ones that vary have no reasonable default value
since they typically represent a bug tracking number or something
similar.
Perhaps --add-header is a better name for this argument. That name at
least makes it clear that headers specified on the command line are
cumulative. If someone has a use case for --no-extra-headers, they
can add it later and --add-header retains the same meaning.
Follow-up patch coming shortly.
--
Michael
next prev parent reply other threads:[~2009-03-26 16:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 15:58 [PATCH] format-patch: add arbitrary email headers Michael Hendricks
2009-03-25 19:11 ` Junio C Hamano
2009-03-26 16:42 ` Michael Hendricks [this message]
2009-03-26 16:51 ` Michael Hendricks
2009-03-26 20:29 ` Junio C Hamano
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=20090326164212.GF29569@ginosko.ndrix.org \
--to=michael@ndrix.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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.