Junio C Hamano <gitster@xxxxxxxxx> writes: > Abhijeet Sonar <abhijeet.nkt@xxxxxxxxx> 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@xxxxxxxxx/ > > 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.
Attachment:
signature.asc
Description: PGP signature
