On Tue, May 07 2019, Denton Liu wrote:

On Wed, May 08, 2019 at 12:05:43AM +0900, Junio C Hamano wrote:

quoted

Denton Liu [off-list ref] writes:

[snip]

quoted

quoted

Would you suggest moving to a format.<branchname>.* approach or would it
make sense to rename the configs to something like
branch.<name>.{emailCoverSubject,emailTo,emailCc}?

So if I have to pick between the two, I would probably vote for the
former from the philosophical ground, but operationally, I suspect
that the latter would be much simpler to use.  You could even have
"git branch -d <name>" to get rid of them at the same time.

But as I may have hinted in the message you are responding to, I am
not quite convinced we want these configuration variables in the
first place.  Why should both description and coverSubject need to
exist?  Perhaps we should add a heuristic like "If the branch
description looks like a single line, optionally followed by 'a
blank line and more paragraphs', use the first line as the subject
of the cover letter (and the remainder as the body of the cover
letter) or something?

I considered doing something like that but I opted not to because it
wouldn't be a backwards compatible change and I didn't want to surprise
any future users with a change like this.

For branch.<branchname>.{to,cc}, I wanted these config options because
the current method for format-patch to handle Cc-lists is just manually
keeping track of the people who have responded and entering them into
the --cc option of format-patch.

This may just be more insanity to implement right now, but perhaps in
addition to "gitdir:" etc. in the IncludeIf config syntax we'd want to
aim for "HEADref" (or some saner name). I.e. allowing to include/enable
arbitrary config based on the ref name.

Chicken & egg problems though...