Junio C Hamano wrote:
> This series has a strong smell of pushing back by the
> toolsmiths who refuse to promptly upgrade to help their users, and
> that is why I do not feel entirely happy with this series.
Last reply, I promise. :)
This sentence might have the key to the misunderstanding. Let me say
a little more about where this showed up in the internal deployment
here, to clarify things a little.
At Google we deploy snapshots of the "next" branch approximately
weekly so that we can find problems early before they affect a
published release. We rely on the ability to roll back quickly when a
problem is discovered, and we might care more about compatibility than
some others because of that.
A popular tool within Google has a bundled copy of Git (also a
snapshot of the "next" branch, but from a few weeks prior) and when we
deployed Git with the EOIE and IEOT extensions, users of that tool
very quickly reported the mysterious message.
That said, the maintainers of that tool did not complain at all, so
hopefully I can allay your worries about toolsmiths pushing back.
Once the problem reached my attention (a few days later than I would
have liked it to), the Git team at Google knew that we could not roll
back and were certainly alarmed about what that means about our
ability to cope with other problems should we need to. But we were
able to quickly update that popular tool --- no issue.
Instead, we ran into a number of other users running into the same
problem, when sharing repositories between machines using sshfs, etc.
That, plus the aforementioned inability to roll back Git if we need
to, meant that this was a serious issue so we quickly addressed it in
the internal installation.
In general, we haven't had much trouble getting people to use Git
2.19.1 or newer. So the problem here does not have to do with users
being slow to upgrade.
Instead, it's simply that upgrading Git should not cause the older,
widely deployed version of Git to complain about the repositories it
acts on. That's a recipe for difficult debugging situations, it can
lead to people upgrading less quickly and reporting bugs later, and
all in all it's a bad situation to be in. I've used tools like
Subversion that would upgrade repositories so they are unusable by the
previous version and experienced all of these problems.
So I consider it important *to Git upstream* to handle this well in
the Git 2.20 release. We can flip the default soon after, even as
soon as 2.21.
Moreover, I am not the only one who ran into this --- e.g. from [1],
2018-10-19:
17:10 <peff> jrnieder: Yes, I noticed that annoyance myself. ;)
17:11 <newren> Yeah, I saw that message a few times and was slightly
annoyed as well.
Now, a meta point. Throughout this discussion, I have been hoping for
some acknowledgement of the problem --- e.g. an "I am sympathetic to
what you are trying to do, but <X>". I wasn't able to find that, and
that is part of what contributed to the feeling of not being heard.
Thanks for your patient explanations, and hope that helps,
Jonathan
[1] https://colabti.org/irclogger/irclogger_log/git-devel?date=2018-10-19#l114
