Denton Liu <liu.denton@xxxxxxxxx> writes:
> diff --git a/Documentation/config/format.txt b/Documentation/config/format.txt
> index dc77941c48..d387451573 100644
> --- a/Documentation/config/format.txt
> +++ b/Documentation/config/format.txt
> @@ -28,14 +28,22 @@ format.headers::
>
> format.to::
> format.cc::
> +format.<branch-name>.to::
> +format.<branch-name>.cc::
> Additional recipients to include in a patch to be submitted
> - by mail. See the --to and --cc options in
> - linkgit:git-format-patch[1].
> + by mail. For the <branch-name> options, the recipients are only
> + included if patches are generated for the given <branch-name>.
> + See the --to and --cc options in linkgit:git-format-patch[1].
An obvious question that somebody else may raise is:
What makes the branch name that special? What guarantees that
it would stay to be the *only* thing that affects the choice of
these variables?
An obvious answer to that is "nothing---we are painting ourselves in
a corner we cannot easily get out of with this design".
If we want to drive format-patch differently depending on the
combination of the worktree location *and* the branch the patches
are generated from, we can do something like:
[includeif "gitdir:/path/to/worktree/1"] path = one.inc
[includeif "gitdir:/path/to/worktree/2"] path = two.inc
and then have one.inc/two.inc have customized definition of these
format.<branch>.{to,cc,...} variables.
But at that point, Ævar's "wouldn't this fit better with includeif"
suggestion becomes more and more appropriate. Once we invent the
way to combine the conditions for includeIf, it would benefit not
just this set of variables but all others that will follow in the
future.
Having said that, as long as we are fine with the plan to deprecate
and remove these three-level variables this patch introdues in the
future, I think it is OK to have them as a temporary stop-gap
measure.
> +format.<branch-name>.coverSubject::
> + When format-patch generates a cover letter for the given
> + <branch-name>, use the specified subject for the cover letter
> + instead of the generic template.
I still think it is a mistake that this has to be given separately
and possibly redundantly from the branch description.
> +static const char *branch_specific_config[] = {
> + "branch",
> + "format",
> + NULL
> +};
Yuck. This will break a workflow where a fixed branch with a known
configuration is deleted and recreated over and over again
(e.g. think of "for-linus" branches used for request-pull in each
merge window).
> static void delete_branch_config(const char *branchname)
> {
> struct strbuf buf = STRBUF_INIT;
> - strbuf_addf(&buf, "branch.%s", branchname);
> - if (git_config_rename_section(buf.buf, NULL) < 0)
> - warning(_("Update of config-file failed"));
> + int i;
> + for (i = 0; branch_specific_config[i]; i++) {
> + strbuf_addf(&buf, "%s.%s", branch_specific_config[i], branchname);
> + if (git_config_rename_section(buf.buf, NULL) < 0)
> + warning(_("Update of config-file failed"));
> + strbuf_reset(&buf);
> + }
This will hardcode the unwarranted limitation that the second level
of the format.*.var hierarchy MUST be branch names and nothing else,
won't it?
