[PATCH] reset: avoid reflog update on no-op reset

[PATCH] reset: avoid reflog update on no-op reset

[Pushkar Singh]

When "git reset" is invoked with a target that already matches HEAD,
it currently writes a reflog entry even though no reference is updated.

Detect this no-op case and avoid updating ORIG_HEAD and HEAD, skipping
the reflog entry entirely.

Add a regression test to ensure no reflog entry is written for a no-op
reset.

Signed-off-by: Pushkar Singh <pushkarkumarsingh1970@gmail.com>
---
 builtin/reset.c   |  4 ++++
 t/t1410-reflog.sh | 15 +++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/builtin/reset.c b/builtin/reset.c
index ed35802af1..900c2f2fe8 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -309,6 +309,10 @@ static int reset_refs(const char *rev, const struct object_id *oid)
 		old_orig = &oid_old_orig;
 	if (!repo_get_oid(the_repository, "HEAD", &oid_orig)) {
 		orig = &oid_orig;
+		if (oideq(orig, oid)) {
+			strbuf_release(&msg);
+			return 0;
+		}
 		set_reflog_message(&msg, "updating ORIG_HEAD", NULL);
 		refs_update_ref(get_main_ref_store(the_repository), msg.buf,
 				"ORIG_HEAD", orig, old_orig, 0,
diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
index ce71f9a30a..54f8692c53 100755
--- a/t/t1410-reflog.sh
+++ b/t/t1410-reflog.sh
@@ -533,6 +533,21 @@ test_expect_success 'reflog for symref with unborn target can be listed' '
 	)
 '
 
+test_expect_success 'reset does not write reflog entry on no-op' '
+	git init no-op-reset &&
+	(
+		cd no-op-reset &&
+		echo a >file &&
+		git add file &&
+		git commit -m initial &&
+
+		before=$(git reflog | wc -l) &&
+		git reset HEAD &&
+		after=$(git reflog | wc -l) &&
+		test "$before" = "$after"
+	)
+'
+
 test_expect_success 'reflog with invalid object ID can be listed' '
 	test_when_finished "rm -rf repo" &&
 	git init repo &&
-- 
2.43.0

Re: [PATCH] reset: avoid reflog update on no-op reset

[Junio C Hamano]

Pushkar Singh <pushkarkumarsingh1970@gmail.com> writes:

> When "git reset" is invoked with a target that already matches HEAD,
> it currently writes a reflog entry even though no reference is updated.
>
> Detect this no-op case and avoid updating ORIG_HEAD and HEAD, skipping
> the reflog entry entirely.

I am mildly negative on this one.  A scripted use that gets which
commit to reset to from the caller in the outside world, e.g.,

    #!/bin/sh
    git reset --hard "$1"
    git diff --stat @{1}

would be confused if reflog does not reliably store the state before
running "reset --hard" to @{1}.  In other words ...

> Add a regression test to ensure no reflog entry is written for a no-op
> reset.

... this change may already be a regression for existing users.

Re: [PATCH] reset: avoid reflog update on no-op reset

[Jeff King]

On Thu, Jan 22, 2026 at 10:57:02AM -0800, Junio C Hamano wrote:

> Pushkar Singh <pushkarkumarsingh1970@gmail.com> writes:
> 
> > When "git reset" is invoked with a target that already matches HEAD,
> > it currently writes a reflog entry even though no reference is updated.
> >
> > Detect this no-op case and avoid updating ORIG_HEAD and HEAD, skipping
> > the reflog entry entirely.
> 
> I am mildly negative on this one.  A scripted use that gets which
> commit to reset to from the caller in the outside world, e.g.,
> 
>     #!/bin/sh
>     git reset --hard "$1"
>     git diff --stat @{1}
> 
> would be confused if reflog does not reliably store the state before
> running "reset --hard" to @{1}.  In other words ...
> 
> > Add a regression test to ensure no reflog entry is written for a no-op
> > reset.
> 
> ... this change may already be a regression for existing users.

I was just writing the same message. ;) In addition to scripted use,
that reflog does contain some human-readable information: the message
field tells us what name we "git reset --hard" to. That might be helpful
when digging through it trying to piece together what happened.

-Peff

Re: [PATCH] reset: avoid reflog update on no-op reset

[Pushkar Singh]

Thanks, that makes sense.

I was reasoning about reflog entries purely in terms of reference
updates, but I see your point that "git reset" also uses the reflog
as a record of user actions, even when the target happens to match
HEAD.

In that light, skipping the reflog entry on a no-op reset could indeed
break the assumption that "@{1}" reliably refers to "the state before
the most recent reset", both for scripts and for humans inspecting
history.

I agree that this makes the change questionable as-is. I’m happy to
drop this patch, or to rework it in a way that preserves the reflog
entry while addressing the underlying concern (if there is one).

Thanks for the detailed explanation.

Re: [PATCH] reset: avoid reflog update on no-op reset

[Junio C Hamano]

Pushkar Singh <pushkarkumarsingh1970@gmail.com> writes:

> ... or to rework it in a way that preserves the reflog
> entry while addressing the underlying concern (if there is one).

I am OK as long as this patch does not come back in its current form
;-), but it is curious what "the underlying concern" is.  It sounds
like you see some problems that need to be addressed if the current
"the act of resetting to the same commit is recorded in the reflog",
but I am not sure what they are.

Thanks.