{"thread":{"id":"57105","subject":"Should update-index --refresh force writing the index in case of racy timestamps?","startedAt":"2021-12-17T10:49:56Z","lastAt":"2021-12-22T11:42:58Z","messageCount":5,"participants":["Marc Strapetz","brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"444339","messageId":"d3dd805c-7c1d-30a9-6574-a7bfcb7fc013@syntevo.com","threadId":"57105","inReplyTo":null,"subject":"Should update-index --refresh force writing the index in case of racy timestamps?","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2021-12-17T10:44:32Z","receivedAt":"2021-12-17T10:49:56Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":"For one of my Git-LFS test repositories, switching between branches \nquite often results in lots of racy index timestamps. Subsequent calls \nto \"git update-index --refresh\" or \"git status\" will invoke the \"lfs\" \nfilter over and over again, just to figure out that all entries are \nstill up-to-date. Hence, the index will never be rewritten and racy \ntimestamps will remain.\n\nTo break out of this state, it seems favorable to write the index if any \nracy timestamp is detected. We will be able to provide a patch if this \nchange sounds reasonable.\n\n-Marc\n"},{"id":"444340","messageId":"505637a9-f6de-8f0d-b5cf-e765388f9301@syntevo.com","threadId":"57105","inReplyTo":"d3dd805c-7c1d-30a9-6574-a7bfcb7fc013@syntevo.com","subject":"Re: Should update-index --refresh force writing the index in case of racy timestamps?","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2021-12-17T11:04:48Z","receivedAt":"2021-12-17T11:04:51Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":"On 17/12/2021 11:44, Marc Strapetz wrote:\n> Subsequent calls to \"git update-index --refresh\" or \"git status\" will invoke the \"lfs\" \n> filter over and over again, ...\n\nPlease forget about the note regarding \"git status\". cmd_status() will \nactually fix racy timestamps by calling repo_update_index_if_able(). So \nthe problem is only about update-index.\n\n-Marc\n"},{"id":"444393","messageId":"Ybz9ruQ/uOfFbn3W@camp.crustytoothpaste.net","threadId":"57105","inReplyTo":"d3dd805c-7c1d-30a9-6574-a7bfcb7fc013@syntevo.com","subject":"Re: Should update-index --refresh force writing the index in case of racy timestamps?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-12-17T21:14:22Z","receivedAt":"2021-12-17T21:14:27Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-12-17 at 10:44:32, Marc Strapetz wrote:\n> For one of my Git-LFS test repositories, switching between branches quite\n> often results in lots of racy index timestamps. Subsequent calls to \"git\n> update-index --refresh\" or \"git status\" will invoke the \"lfs\" filter over\n> and over again, just to figure out that all entries are still up-to-date.\n> Hence, the index will never be rewritten and racy timestamps will remain.\n> \n> To break out of this state, it seems favorable to write the index if any\n> racy timestamp is detected. We will be able to provide a patch if this\n> change sounds reasonable.\n\nSure, this sounds reasonable, especially if, as you mentioned, git\nstatus already does this.  We might as well make the plumbing commands\nas functional as the porcelain commands.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"444403","messageId":"xmqqee6a22rj.fsf@gitster.g","threadId":"57105","inReplyTo":"Ybz9ruQ/uOfFbn3W@camp.crustytoothpaste.net","subject":"Re: Should update-index --refresh force writing the index in case of racy timestamps?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-18T00:08:32Z","receivedAt":"2021-12-18T00:08:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> On 2021-12-17 at 10:44:32, Marc Strapetz wrote:\n>> For one of my Git-LFS test repositories, switching between branches quite\n>> often results in lots of racy index timestamps. Subsequent calls to \"git\n>> update-index --refresh\" or \"git status\" will invoke the \"lfs\" filter over\n>> and over again, just to figure out that all entries are still up-to-date.\n>> Hence, the index will never be rewritten and racy timestamps will remain.\n>> \n>> To break out of this state, it seems favorable to write the index if any\n>> racy timestamp is detected. We will be able to provide a patch if this\n>> change sounds reasonable.\n>\n> Sure, this sounds reasonable, especially if, as you mentioned, git\n> status already does this.  We might as well make the plumbing commands\n> as functional as the porcelain commands.\n\nGiven that \"update-index --refresh\" is a way to say \"we know\nsomething changed to make cached stat information dirty even for\notherwise clean paths and we want our 'diff-files' and other\nplumbing command to start relying on the cached stat information\nagain, so please do as much I/O as you need\", I agree that it should\ndo as thourough job as necessary.\n"},{"id":"444766","messageId":"5a74b0bc-d713-e8bf-5952-dbaaf5d886e7@syntevo.com","threadId":"57105","inReplyTo":"xmqqee6a22rj.fsf@gitster.g","subject":"Re: Should update-index --refresh force writing the index in case of racy timestamps?","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2021-12-22T11:42:52Z","receivedAt":"2021-12-22T11:42:58Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":"On 18/12/2021 01:08, Junio C Hamano wrote:\n> \"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n> \n>> On 2021-12-17 at 10:44:32, Marc Strapetz wrote:\n>>> For one of my Git-LFS test repositories, switching between branches quite\n>>> often results in lots of racy index timestamps. Subsequent calls to \"git\n>>> update-index --refresh\" or \"git status\" will invoke the \"lfs\" filter over\n>>> and over again, just to figure out that all entries are still up-to-date.\n>>> Hence, the index will never be rewritten and racy timestamps will remain.\n>>>\n>>> To break out of this state, it seems favorable to write the index if any\n>>> racy timestamp is detected. We will be able to provide a patch if this\n>>> change sounds reasonable.\n>>\n>> Sure, this sounds reasonable, especially if, as you mentioned, git\n>> status already does this.  We might as well make the plumbing commands\n>> as functional as the porcelain commands.\n> \n> Given that \"update-index --refresh\" is a way to say \"we know\n> something changed to make cached stat information dirty even for\n> otherwise clean paths and we want our 'diff-files' and other\n> plumbing command to start relying on the cached stat information\n> again, so please do as much I/O as you need\", I agree that it should\n> do as thourough job as necessary.\n\nThanks! I have now submitted a pull request via gitgitgadget.\n\nI had some problems to understand what the correct place to set \nactive_cache_changed is and have decided to keep it as close as possible \nto refresh_cache(): unresolve_callback() and reupdate_callback() may \nreset active_cache_changed in case of errors. On the other hand, \nactive_cache_changed may be set again later for a preferred_index_format \nchange and for read_from_stdin (as part of update_one()), so in the end \nthe callbacks may be overruled and the index may finally be written. I'm \nnot sure whether these combinations can actually occur and whether this \nmight cause any troubles. I just wanted to point out.\n\n-Marc\n"}]}