Re: [PATCH 1/2] Add possibility to store configuration in ~/.config/git/config file

From: Jeff King <peff@peff.net>
Date: May 25, 2012, 21:44 UTC
Message-ID: <20120525214406.GA10064@sigill.intra.peff.net>
In-Reply-To: <7vd35sq7fx.fsf@alter.siamese.dyndns.org>

On Fri, May 25, 2012 at 02:25:38PM -0700, Junio C Hamano wrote:

Show 15 quoted lines

> > At first people will have only one or the other, but people using
> > multiple versions of git, or people following already-written
> > instructions on the web about modifying ~/.gitconfig could end up with
> > both.
> 
> Isn't it actually much worse than that?
> 
> If you read from .gitconfig and also from the new location, but update
> only the new location, people who use two versions of git will be in a
> very confusing situation.  Randomly, some of their updates are always in
> effect, and others only appear sometimes, and after wasting a lot of time
> and hair scratching their heads, they will realize that writing with old
> versions of Git will store values to a place visible to both versions,
> while writing with new versions will store values to a place visible only
> to new versions.

That's true, but...

Show 13 quoted lines

> I'd rather see it ignore the new location as long as ~/.gitconfig exists
> (and if only the new location exists, read from and write to it), and have
> users make a conscious decision to transition.  That is:
> 
>  - If ~/.gitconfig exists, do not do anything new.  Just exercise the
>    original code.  For these users, ~/.config/ does _not_ exist as far as
>    Git is concerned.
> 
>  - (optional) If ~/.gitconfig exists, offer _moving_ it to the new
>    location after telling the user to make sure that the user will never
>    use older version of git again, and move it if the user agrees.
> 
>  - Otherwise, read from and write to the new location.

That doesn't solve all problems with multiple versions, though. For example, this sequence:

  1. User consciously moves to new location, moving ~/.gitconfig to
     ~/.config/git/config (or perhaps they do not do so consciously, but
     do not have a ~/.gitconfig at all, and run "git config --global"
     with the new version.

  2. User runs "git config --global" with an old version of git, which
     writes to ~/.gitconfig.

After step 1, old versions of git will not respect the user's config at all. This is unavoidable; the old version does not know about the new location.

But after step 2, _all_ versions of git have stopped respecting the new location (because ~/.gitconfig takes precedence). Whereas if we read from everywhere, then it is broken only in older versions (which are broken anyway).

So I consider it the lesser of two evils. The rule is much simpler: "old versions of git do not know about this new location". Which is unavoidable, and easier to explain than "Old versions of git do not know about this location. New versions do, but will sometimes ignore depending on whether this other file exists, which might have been created by an old version".

However, let's take a step back for a minute. I think the real issue is writing to the XDG location without the user knowing about it. So a better transition plan would be:

  1. Start reading from the XDG location in addition to the old
     location. Always write to the old location.

  2. Wait N time units until everybody reasonable has a version that
     does (1).

  3. Start writing to the XDG location by default. Keep reading from the
     old version for compatibility.

People who want to start using the new location after step 1 are free to do so; they just shouldn't expect git to write to it, and they should accept the obvious caveat that older versions of git will not understand it. An optional addendum is that we could start writing to the XDG location after step 1 only if it exists, which implies that the user has decided it's OK to do so (which is still a guess; they might have wanted to split their config intentionally).

-Peff