git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: A puzzle: reset --hard and hard links

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 26, 2022, 18:46 UTC
Message-ID
<xmqqsftas5c8.fsf@gitster.g>
In-Reply-To
<YfCue6m4gqGEWqDj@camp.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 7 quoted lines
> Thanks, this is helpful context and it explains why you'd want this
> behavior.  If you're involved with the project, it may be helpful to
> point out to other project members that this occurs and suggest that the
> scripts avoid running "git reset --hard".  For example, it may be easy
> to avoid if "git status --porcelain" produces empty output.  I've heard
> stories about Chromium's build times and I'm sure such an optimization
> would be welcome.

I am not sure about that. If the ONLY problem is that hardlinks to UNMODIFIED paths are severed by "reset --hard" when it is not necessary in order to ensure that HEAD and the working tree matches in content without clobbering anything unrelated, then adding an internal call to refresh before "git reset --hard" would neatly solve it, and there should not be a need for end-user workaround like that.

But it does not change the fact that we try to avoid clobbering anything unrelated to the path we are updating when we need to update the contents of the working tree files, and the way we do so is to call checkout_entry(), which does unlink() followed by creat(). So even though you may be able to teach "git reset --hard" to refrain from severing extra hardlinks when it does not have to, it will do so when the contents of the path must be changed.

To be quite honest, I am not sure if the patch below is safe either. I doubt that the lack of "update-index --refresh" in the "reset --hard" command was a mistake; rather, I suspect that it was deliberately omitted to avoid some problems, which I do not offhand recall.

 builtin/reset.c | 1 +
 1 file changed, 1 insertion(+)
diff --git c/builtin/reset.c w/builtin/reset.c
index b97745ee94..8adc1be75b 100644
--- c/builtin/reset.c
+++ w/builtin/reset.c
@@ -83,6 +83,7 @@ static int reset_index(const char *ref, const struct object_id *oid, int reset_t
 	}
 
 	read_cache_unmerged();
+	refresh_cache(REFRESH_QUIET);
 
 	if (reset_type == KEEP) {
 		struct object_id head_oid;
Previous: brian m. carlson
Message 18 of 18 in “A puzzle: reset --hard and hard links”
  1. Michael HerrmannJan 19, 2022
  2. brian m. carlsonJan 19, 2022
  3. Junio C HamanoJan 19, 2022
  4. Michael HerrmannJan 20, 2022
  5. brian m. carlsonJan 20, 2022
  6. Michael HerrmannJan 21, 2022
  7. Michael HerrmannJan 24, 2022
  8. Junio C HamanoJan 24, 2022
  9. Michael HerrmannJan 24, 2022
  10. Junio C HamanoJan 24, 2022
  11. rsbecker@nexbridge.comJan 24, 2022
  12. Michael HerrmannJan 24, 2022
  13. Andreas SchwabJan 25, 2022
  14. Ævar Arnfjörð BjarmasonJan 25, 2022
  15. Andreas SchwabJan 25, 2022
  16. Michael HerrmannJan 25, 2022
  17. brian m. carlsonJan 26, 2022
  18. Junio C HamanoJan 26, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.