On Fri, May 25, 2012 at 02:25:38PM -0700, Junio C Hamano wrote:
> > 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...
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html