Re: [PATCH v3] advice: use global config for default branch name

[Junio C Hamano <gitster@pobox.com>]

Vsevolod Myalitsin <ub4nal@mail.ru> writes:

> I have one question about how the series should be organized. Since the
> three patches will have different purposes, should each patch have its
> own subject and commit message describing the changes introduced by that
> patch? Or should they share a common subject/theme, with the individual
> changes described in the respective commit messages?

Sorry, but I do not quite understand what is being asked.

For example, if you had a 4-patch series like

  https://lore.kernel.org/git/20260909-758-introduce-hook-v9-0-3043d417e0ee@gmail.com/

how would you characterize each patch in it?  These 4 patches share
the same goal in bigger picture (after all that is why they are in a
single series) yet each step has its own agenda (each of them can be
explained separately as a logical unit, and that is why you are
making them separate patches to ease reading and understanding).
Each patch comes with its own title and explian the background (the
observation of the status quo) and what it wants to solve and how.

Your three-patch series would be quite similar.  If you want to
describe the motivation and overall structure of the solution, a
cover letter would make a good place to do so, and then each patch
does so in a smaller scale in its proposed log message.
The contents of each message may begin like so:

 [0/3] defaultBranchName advice is useless

 It does not make much sense to set the advice.defaultBranchName
 configuration variable in a per-repository configuration file, as
 once a repository is initialized, the advice will never fire.  We
 need to mechanism to mark such advice messages so that the message
 to tell what advice.* variable to tweak can suggest doing so in a
 per-user or even per-system configuration files.

 This series consists of three steps, ...

 [1/3] advice: pass the entire advice_setting to vadvise()

 The internal function vadvice() takes values taken from members of
 an advice_settings struct individually, which is cumbersome to
 extend.  Instead, pass the advice_settings instance so that the
 function can be extended by adding new members ot advnce_settings
 struct, without changing the signature of vadvise() function.

 [2/3] advice: introduce advice scoping mechanism

 The hint on how to squelch advice message told users to set
 advice.X configuration variable to false to squelch it, but for
 some variables, setting it globally in per-user configuration file
 is more appropriate.  Add a new member to advice_settings struct to
 indicate which config scope the variable should be set, and adjust
 the message.

...

By the way, when you prepare a v4, make sure that the cover letter
of the 3-patch series is a reply to your v3 patch, and each patch in
the series is a reply to the cover letter of v4.  That would give us
a nice threading on the mailing list archive and help automation.

Thanks.