From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Sat, 26 May 2012 10:15:13 GMT
Subject: Re: [PATCH 1/2] Add possibility to store configuration in ~/.config/git/config file
Message-ID: <CACsJy8BD_=6PtQeuDGEt2mee9tMWZB1hL2obu2f2KUmAENTEzA@mail.gmail.com>
In-Reply-To: <20120525214406.GA10064@sigill.intra.peff.net>

On Sat, May 26, 2012 at 4:44 AM, Jeff King <peff@peff.net> wrote:
>> 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".

We could amend Junio's version a bit:

 - if both versions exist, warn loudly (optionally refuse to work) and
suggest to symlink .gitconfig to .config/git/config


> 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.

Hang on.. this "by default" is only for Linux, or for every other OS too?


> 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).
-- 
Duy