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

From: Duy Nguyen <pclouds@gmail.com>
Date: Jan 9, 2017, 10:55 UTC
Message-ID: <CACsJy8AR6yNr0y+_JZDkW-HO_yHPkUx_6zbLGoviKQBOVcSg5A@mail.gmail.com>
In-Reply-To: <xmqqo9zi35n6.fsf@gitster.mtv.corp.google.com>

On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

> 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). In both cases we silently ignore utime() error (sha1_file.c does retry, but will do nothing else if the retry fails). And errors in odb are much more serious than index files. If we are to improve it, I think we should do it inside check_and_freshen_file(), maybe with an optional flag to silence it.

Show 12 quoted lines

> Isn't a failure to freshen it a grave error?  We are letting a
> base/shared index file that is known to be in-use go stale and
> eventually subject for garbage collection, and the user should be
> notified in some way before the actual GC happens that renders the
> index file unusable?
>
> 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.

-- 
Duy