Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes:

> I had a slight bias against this when you started this, since I'm one of
> these odd people who don't mind ~20k line files if the line count isn't
> contributing to inherent complexity, e.g. in the case of config.txt you
> could just use the search function all in one file.

After typing "less Documentation/config.txt" and realizing that I
have to open another file (which one?) to find how we described the
push.default config, I am already experiencing a lot stronger bias
against this.

But I know it will pass.  Once this ~60 patch series completes, my
irritation would peak, because at that point I would not be able to
even do "git grep push.config Documentation/config*", but I would no
longer be reaching for "less Documentation/config.txt" anymore at
that point.  Once Documentation/$group-config.txt (which I think is
a mistake) are renamed to Documentation/$something/$group.txt, then
I know I can do "less Doc<TAB>/$some<TAB>/$gro<TAB>" to get my ease
of use back.  There will still be an annoyance caused by having to
open another file when reading description of branch.<name>.merge in
branch-config.txt and seeing a reference to push.default, though.

And the end result makes it impossible to place a description of a
new variable in a wrong section.  It still is possible to mistakenly
insert a variable in a wrong place in the right section that
requires a fix like 8578037b ("config.txt: reorder blame stuff to
keep config keys sorted", 2018-08-04), but we do not fix all the
problems under the sky in one series ;-).

So after saying all of the above, I am moderately supportive of this
series.

Reply via email to