Re: [PATCH v2 0/6] teach branch-specific options for format-patch

From: Junio C Hamano <gitster@pobox.com>
Date: May 17, 2019, 04:12 UTC
Message-ID: <xmqqk1ep3ejv.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <cover.1558052674.git.liu.denton@gmail.com>

Denton Liu <liu.denton@gmail.com> writes:

Show 16 quoted lines

> 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.

Show 5 quoted lines

> +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).

Show 13 quoted lines

>  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?