From: Karthik Nayak Date: Sun, 30 Jun 2024 16:12:12 GMT Subject: Re: [PATCH v7] describe: refresh the index when 'broken' flag is used Message-ID: In-Reply-To: Junio C Hamano writes: > Abhijeet Sonar writes: > >> I have a question: >> >> Why does --dirty code path also not call git-update-index and instead does >> >> setup_work_tree(); >> prepare_repo_settings(the_repository); >> the_repository->settings.command_requires_full_index = 0; >> repo_read_index(the_repository); >> refresh_index(...); >> fd = repo_hold_locked_index(...); >> if (0 <= fd) >> repo_update_index_if_able(the_repository, &index_lock); >> >> I assume they are equivalent? > > Now we are going back full circles ;-)? > > Your earliest attempt indeed copied the above to the code paths used > to handle "--broken", but then Phillip corrected the course > > https://lore.kernel.org/git/054c6ac1-4714-4600-afa5-7e9b6e9b0e72@gmail.com/ > > to avoid triggering an in-process error and instead run an > equivalent "update-index --refresh" via the run_command() interface, > so that we can catch potential errors. The code in the more recent > rounds of your patch uses that, no? > This explains for why 'broken' must use a subprocess, but there is nothing stopping 'dirty' from also using a subprocess, right? It currently uses an in-process index refresh but it _could_ be a subprocess too. Does it need to be a subprocess? I can't think of any reason to make it.