Re: [PATCH 5/5] index: offer advice for unknown index extensions

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Nov 21 2018, Jonathan Nieder wrote:

> 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

I think it makes total sense to fix this. I had not spotted this myself
since I tend to just roll forward and only use one version of git on one
system, but fixing this makes sense.