Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> Add a CONFIGURATION section to the documentation of various built-ins,
> for those cases where the relevant config/NAME.txt doesn't map only to
> one git-NAME.txt. In particular:
>
> * config/blame.txt: used by git-{blame,annotate}.txt. Since the
> git-annotate(1) documentation refers to git-blame(1) don't add a
> "CONFIGURATION" section to git-annotate(1), only to git-blame(1)>
s/>/./ I think.
> * config/branch.txt: maps to both git-checkout.txt and
> git-switch.txt (but nothing else).
s|/branch.txt|/checkout.txt|, I think.
> * config/init.txt: should be included in git-init(1) and
> git-clone(1).
>
> * config/column.txt: We should ideally mention the relevant subset of
> this in git-{branch,clean,status,tag}.txt, but let's punt on it for
> now. We will when we eventually split these sort of files into
> e.g. config/column.txt and
> config/column/{branch,clean,status,tag}.txt, with the former
> including the latter set.
>
> Things that are being left out, and why:
>
> * config/remote.txt: let's not include this in
> git-{fetch,remote,push}.txt etc. for now, various options there
> change their behavior.
Leaving some stuff out is fine, but I am not sure I understand
(note: I didn't say "I agree with") the reasoning. I take "various
options there" to mean the configuration variables described in
config/remote.txt file? If these variables affect the behaviour of
commands like fetch, remote, and push, isn't it more reason to
include the description of them?
