From: Matt McCutchen <matt@mattmccutchen.net>
To: Johannes Sixt <j.sixt@viscovery.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] config.txt: alphabetize configuration variable groups
Date: Mon, 24 Nov 2008 15:00:09 -0500 [thread overview]
Message-ID: <1227556809.2628.8.camel@mattlaptop2.local> (raw)
In-Reply-To: <492A579B.5000304@viscovery.net>
On Mon, 2008-11-24 at 08:28 +0100, Johannes Sixt wrote:
> Matt McCutchen schrieb:
> > @@ -963,6 +953,8 @@ man.<tool>.path::
> > Override the path for the given tool that may be used to
> > display help in the 'man' format. See linkgit:git-help[1].
> >
> > +include::merge-config.txt[]
> > +
> > merge.conflictstyle::
> > Specify the style in which conflicted hunks are written out to
> > working tree files upon merge. The default is "merge", which
>
> Here, the list is not in alphabetic order anymore.
After my change, the list is in alphabetical order by the first
component (before the first dot). I assume you're pointing out that I
haven't separated the merge.<driver> parameters from the non-<driver>
merge parameters.
The reason I left it that way was I thought there might be some reason
why merge.conflictstyle is in config.txt rather than merge-config.txt
(the difference being that it appears in "man git-config" but not
"man git-merge"), and to keep that arrangement while grouping together
the non-<driver> merge parameters, I would have to split
merge-config.txt into two separately included files.
I went back and looked at the commit (b5412484) that documented
merge.conflictstyle, and it appears that the placement in config.txt may
have been a mistake arising from the unsortedness of config.txt rather
than a conscious decision. Thus, I'll move that entry to
merge-config.txt for the better grouping. That does mean "man
git-merge" will contain two explanations of merge.conflictstyle (the
brief config-parameter one and the "HOW CONFLICTS ARE PRESENTED"
section), but I don't see that as a big problem.
> BTW, your commit message should emphasize the use-cases where an
> alphabetic order is a real benefit. Otherwise, this is just code churn.
I don't see alphabetization as a major benefit except that it might help
people add new parameters in the right place (case in point: the
addition of merge.conflictstyle). And I figured that the config
parameters might as well be in /some/ order. I'll state that in the
commit message.
Updated patch to follow.
Matt
next prev parent reply other threads:[~2008-11-24 20:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-24 7:01 [PATCH] config.txt: alphabetize configuration variable groups Matt McCutchen
2008-11-24 7:28 ` Johannes Sixt
2008-11-24 20:00 ` Matt McCutchen [this message]
2008-11-26 8:26 ` [PATCH v2] config.txt: alphabetize configuration sections Matt McCutchen
-- strict thread matches above, loose matches on Subject: below --
2008-10-19 1:42 [PATCH] config.txt: alphabetize configuration variable groups Matt McCutchen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1227556809.2628.8.camel@mattlaptop2.local \
--to=matt@mattmccutchen.net \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).