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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 9, 2017, 14:34 UTC
Message-ID: <xmqqvatouwsh.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACsJy8AR6yNr0y+_JZDkW-HO_yHPkUx_6zbLGoviKQBOVcSg5A@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 10 quoted lines

> On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Christian Couder <christian.couder@gmail.com> writes:
>>
>>> So what should we do if freshen_file() returns 0 which means that the
>>> freshening failed?
>>
>> You tell me ;-)  as you are the one who is proposing this feature.
>
> My answer is, we are not worse than freshening loose objects case
> (especially since I took the idea from there).

I do not think so, unfortunately. Loose object files with stale timestamps are not removed as long as objects are still reachable. For the base/shared index file, the timestamp is the only thing that protects them from pruning, unless it is serving as the base file for the currently active $GIT_DIR/index that is split.

Show 11 quoted lines

>> What is the failure mode after such a premature GC happens?  What
>> does the end-user see?  Can you try to (1) split the index (2)
>> modify bunch of entries (3) remove the base/shared index with /bin/rm
>> and then see how various Git commands fail?  Do they fail gracefully?
>>
>> I am trying to gauge the seriousness of ignoring such an error here.
>
> If we fail to refresh it and the file is old enough and gc happens,
> any index file referenced to it are broken. Any commands that read the
> index will die(). The best you could do is delete $GIT_DIR/index and
> read-tree HEAD.