Re: [PATCH v3 14/21] read-cache: touch shared index files when used

From: Christian Couder <christian.couder@gmail.com>
Date: Jan 25, 2017, 14:35 UTC
Message-ID: <CAP8UFD3KXOgVOhuMtws36XPiek56U4mQKdUs07hzKc-dC=ppmA@mail.gmail.com>
In-Reply-To: <xmqqefztsj4c.fsf@gitster.mtv.corp.google.com>

On Mon, Jan 23, 2017 at 7:53 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 21 quoted lines

> Christian Couder <christian.couder@gmail.com> writes:
>
>> Also in general the split-index mode is useful when you often write
>> new indexes, and in this case shared index files that are used will
>> often be freshened, so the risk of deleting interesting shared index
>> files should be low.
>> ...
>>> Not that I think freshening would actually fail in a repository
>>> where you can actually write into to update the index or its refs to
>>> make a difference (iow, even if we make it die() loudly when shared
>>> index cannot be "touched" because we are paranoid, no real life
>>> usage will trigger that die(), and if a repository does trigger the
>>> die(), I think you would really want to know about it).
>>
>> As I wrote above, I think if we can actually write the shared index
>> file but its freshening fails, it probably means that the shared index
>> file has been removed behind us, and this case is equivalent as when
>> loose files have been removed behind us.
>
> OK, so it is unlikely to happen, and when it happens it leads to a
> catastrophic failure---do we just ignore or do we report an error?

Well, when we cannot freshen a loose file (with freshen_loose_object()), we don't warn or die, we just write the loose file. But here we cannot write the shared index file.

And this doesn't lead to a catastrophic failure right away. There could be a catastrophic failure if the shared index file is needed again later, but we are not sure that it's going to be needed later. In fact it may have just been removed because it won't be needed later.

So I am not sure it's a good idea to anticipate a catastrophic failure that may not happen. Perhaps we could just warn, but I am not sure it will help the user. If the catastrophic failure doesn't happen because the shared index file is not needed, I can't see how the warning could help. And if there is a catastrophic failure, the following will be displayed:

fatal: .git/sharedindex.cbfe41352a4623d4d3e9757861fed53f3094e0ac: index file open failed: No such file or directory

and I don't see how the warning could help on top of that. It could at most repeat the same thing.