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

2 messages, 2 authors, 2017-01-09 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2017-01-07 21:46:29

Christian Couder [off-list ref] 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.

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.

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

From: Duy Nguyen <hidden>
Date: 2017-01-09 10:57:18

On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano [off-list ref] wrote:
Christian Couder [off-list ref] writes:
quoted
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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help