Re: [PATCH 0/7] teach branch-specific options for format-patch
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 7, 2019, 15:05 UTC
- Message-ID
- <xmqq36lql2yg.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20190507141942.GA359@archbookpro.localdomain>
Denton Liu <liu.denton@gmail.com> writes:
Show 5 quoted lines
> 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.
Show 6 quoted lines
>> 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?