On Tue, May 07 2019, Denton Liu wrote:
> On Wed, May 08, 2019 at 12:05:43AM +0900, Junio C Hamano wrote:
>> Denton Liu <liu.denton@xxxxxxxxx> writes:
>
> [snip]
>
>> >
>> > 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...
