git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Zach <zach@letmesearchthat.com>, git@vger.kernel.org
Subject: Re: Alphabetize git config --list
Date: Tue, 29 May 2012 04:49:40 -0400	[thread overview]
Message-ID: <20120529084940.GA15145@sigill.intra.peff.net> (raw)
In-Reply-To: <4FC45CEB.4070808@alum.mit.edu>

On Tue, May 29, 2012 at 07:21:47AM +0200, Michael Haggerty wrote:

> >>Essentially this
> >>$ git config --list | sort
> >
> >No, it's not a good idea; the order of keys is important. For example,
> >[...]
> 
> Is the order of *keys* important, or only the order of *values* for a
> given key?  I believe that one could sort the output by key as long
> as the values for each key are kept in their original order (i.e.,
> sort stably by key).  This would indeed make it easier to read the
> output.

Good question. I was thinking of the order of values, but you're right
that a stable key-only sort would handle that.

In general, keys are independent, but there are two exceptions I can
think of:

  1. We sometimes have aliased keys that get parsed to the same memory
     location (usually this is to maintain backwards compatibility when
     a key is renamed, or wants to grow incompatible features). For
     example, "diff.color" and "color.diff" override each other, and
     their order is important. Also, "diff.funcname" and "diff.xfuncname".
     There may also be others.

  2. Keys which involve pattern matching. The url.*.insteadOf keys seem
     to be order-independent, as they the longest match is used, not the
     first. The credential context-matching code takes all matches
     (though technically, things like the order in which helpers are
     called would be changed by a sort). I can't think of any others
     offhand.

So yes, I think the key order does matter, though only in a few corner
cases.

-Peff

      reply	other threads:[~2012-05-29  8:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-28 20:58 Alphabetize git config --list Zach
2012-05-28 21:23 ` Jeff King
2012-05-29  5:21   ` Michael Haggerty
2012-05-29  8:49     ` Jeff King [this message]

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=20120529084940.GA15145@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=mhagger@alum.mit.edu \
    --cc=zach@letmesearchthat.com \
    /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).