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