Hi,
Ben Peart wrote:
> While I can understand the user confusion the warning about ignoring an
> extension could cause I guess I'm a little surprised that people would see
> it that often. To see the warning means they are running a new version of
> git in the same repo as they are running an old version of git. I just
> haven't ever experienced that (I only ever have one copy of git installed)
> so am surprised it comes up often enough to warrant this change.
Great question. There are a few contexts where it comes up:
1. Using multiple versions of Git on a single machine. For example,
some IDEs bundle a particular version of Git, which can be a
different version from the system copy, or on a Mac, /usr/bin/git
quickly goes out of sync with the Homebrew git in
/usr/local/bin/git.
2. Sharing a single Git repository between multiple machines. This is
not unusual, using NFS or sshfs, for example.
3. Downgrading after trying a new version of Git.
To support these, Git is generally careful to avoid writing
repositories that older versions of Git do not understand. The EOIE
extension was almost perfect in this respect: it works fine with older
versions of Git, except for the alarming error message.
> That said, if it _is_ that much of an issue, this patch makes sense and
> provides a way to more gracefully transition into this feature. Even if we
> had some logic to dynamically determine whether to write it or not, we'd
> still want to avoid confusing users when it did get written out.
Yes. An earlier version of this patch defaulted to writing EOIE if
and only if the .git/index file already has an EOIE extension. There
were enough holes in that (commands like "git reset" that do not read
the existing index file) and enough complexity that it didn't seem
worth it.
Really in this series, patch 3/3 is the one I care most about. I wish
we had had it years ago. :) It would make patches 1 and 2
unnecessary.
Thanks,
Jonathan
