Should update-index --refresh force writing the index in case of racy timestamps?

3 messages, 2 authors, 2021-12-17 · open the first message on its own page

Should update-index --refresh force writing the index in case of racy timestamps?

From: Marc Strapetz <hidden>
Date: 2021-12-17 10:49:56

For one of my Git-LFS test repositories, switching between branches 
quite often results in lots of racy index timestamps. Subsequent calls 
to "git update-index --refresh" or "git status" will invoke the "lfs" 
filter over and over again, just to figure out that all entries are 
still up-to-date. Hence, the index will never be rewritten and racy 
timestamps will remain.

To break out of this state, it seems favorable to write the index if any 
racy timestamp is detected. We will be able to provide a patch if this 
change sounds reasonable.

-Marc

Re: Should update-index --refresh force writing the index in case of racy timestamps?

From: Marc Strapetz <hidden>
Date: 2021-12-17 11:04:51

On 17/12/2021 11:44, Marc Strapetz wrote:
Subsequent calls to "git update-index --refresh" or "git status" will invoke the "lfs" 
filter over and over again, ...
Please forget about the note regarding "git status". cmd_status() will 
actually fix racy timestamps by calling repo_update_index_if_able(). So 
the problem is only about update-index.

-Marc

Re: Should update-index --refresh force writing the index in case of racy timestamps?

From: brian m. carlson <hidden>
Date: 2021-12-17 21:14:27

On 2021-12-17 at 10:44:32, Marc Strapetz wrote:
For one of my Git-LFS test repositories, switching between branches quite
often results in lots of racy index timestamps. Subsequent calls to "git
update-index --refresh" or "git status" will invoke the "lfs" filter over
and over again, just to figure out that all entries are still up-to-date.
Hence, the index will never be rewritten and racy timestamps will remain.

To break out of this state, it seems favorable to write the index if any
racy timestamp is detected. We will be able to provide a patch if this
change sounds reasonable.
Sure, this sounds reasonable, especially if, as you mentioned, git
status already does this.  We might as well make the plumbing commands
as functional as the porcelain commands.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help