On Wed, Mar 25, 2009 at 12:11:02PM -0700, Junio C Hamano wrote: > Michael Hendricks <michael@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
