Denton Liu <liu.denton@xxxxxxxxx> writes:
> The reason why I chose to use branch.<name>.* is because format-patch
> currently reads from branch.<name>.description and I wanted to build on
> top of that. In addition, I didn't want to scatter branch-specific
> configs in two different place (i.e. have a branch.<branchName>.description
> alongside a format.<branchName>.coverSubject).
The "branch.<name>.description" variable lives at a lot higher level
of abstraction than "use this for the default value of option X of
the command Y". It gives a place for the user to state what the
branch is about. It makes 100% sense not to have it under format.*
hierarchy, because it is designed to be agnostic to what individual
command uses it for. It is there to talk about what the branch is
for, and what the variable says about the branch to its users,
i.e. various tools, does not change depending on who is listening to
it.
The format-patch command may use it as a hint for writing the cover
letter message. Repository browsers may use it while listing the
branches when more descriptive text than the branch name is desired.
Request-pull tool may use it when preparing the branch summary.
The point is that "description" is about "what that *branch* is",
not "what that branch means for the format-patch user".
You cannot compare that with something like "when format-patch
prepares an e-mail, add CC: header to this address", which is very
specific to the single command, i.e. "how command X uses it". I
think that is the gist of the new variables you are adding.
>> In any case, it smells to me that branch.<branch>.cc does not hint
>> strongly enough that they are meant to affect format-patch.
>
> 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?
