git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "Michael Herrmann" <michael@herrmann.io>,
	"Andreas Schwab" <schwab@linux-m68k.org>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org
Subject: Re: A puzzle: reset --hard and hard links
Date: Wed, 26 Jan 2022 10:46:15 -0800	[thread overview]
Message-ID: <xmqqsftas5c8.fsf@gitster.g> (raw)
In-Reply-To: <YfCue6m4gqGEWqDj@camp.crustytoothpaste.net> (brian m. carlson's message of "Wed, 26 Jan 2022 02:14:19 +0000")

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> 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;

  reply	other threads:[~2022-01-26 18:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-19 20:37 A puzzle: reset --hard and hard links Michael Herrmann
2022-01-19 22:20 ` brian m. carlson
2022-01-19 22:37   ` Junio C Hamano
2022-01-20  8:59     ` Michael Herrmann
2022-01-20 22:20       ` brian m. carlson
2022-01-21 12:50         ` Michael Herrmann
2022-01-24 13:48           ` Michael Herrmann
2022-01-24 18:07             ` Junio C Hamano
2022-01-24 18:16               ` Michael Herrmann
2022-01-24 21:19                 ` Junio C Hamano
2022-01-24 21:50                   ` Michael Herrmann
2022-01-25  8:49                     ` Andreas Schwab
2022-01-25 11:33                     ` Ævar Arnfjörð Bjarmason
2022-01-25 13:29                       ` Andreas Schwab
2022-01-25 14:30                         ` Michael Herrmann
2022-01-26  2:14                           ` brian m. carlson
2022-01-26 18:46                             ` Junio C Hamano [this message]
2022-01-24 22:18                   ` rsbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqsftas5c8.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=michael@herrmann.io \
    --cc=sandals@crustytoothpaste.net \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).