{"thread":{"id":"64855","subject":"Re: [PATCH] reset: avoid reflog update on no-op reset","startedAt":"2026-01-23T08:54:20Z","lastAt":"2026-01-23T16:18:19Z","messageCount":2,"participants":["Pushkar Singh","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"534528","messageId":"SL2P216MB1885C5C9B75A38AE99E5511DA294A@SL2P216MB1885.KORP216.PROD.OUTLOOK.COM","threadId":"64855","inReplyTo":null,"subject":"Re: [PATCH] reset: avoid reflog update on no-op reset","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-01-23T08:54:15Z","receivedAt":"2026-01-23T08:54:20Z","isPatch":true,"sender":{"key":"pushkarkumarsingh1970@gmail.com","avatar":"https://avatars.githubusercontent.com/u/173247767?v=4"},"body":"Thanks, that makes sense.\n\nI was reasoning about reflog entries purely in terms of reference\nupdates, but I see your point that \"git reset\" also uses the reflog\nas a record of user actions, even when the target happens to match\nHEAD.\n\nIn that light, skipping the reflog entry on a no-op reset could indeed\nbreak the assumption that \"@{1}\" reliably refers to \"the state before\nthe most recent reset\", both for scripts and for humans inspecting\nhistory.\n\nI agree that this makes the change questionable as-is. I’m happy to\ndrop this patch, or to rework it in a way that preserves the reflog\nentry while addressing the underlying concern (if there is one).\n\nThanks for the detailed explanation."},{"id":"534556","messageId":"xmqq7bt8joae.fsf@gitster.g","threadId":"64855","inReplyTo":"SL2P216MB1885C5C9B75A38AE99E5511DA294A@SL2P216MB1885.KORP216.PROD.OUTLOOK.COM","subject":"Re: [PATCH] reset: avoid reflog update on no-op reset","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-01-23T16:18:17Z","receivedAt":"2026-01-23T16:18:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pushkar Singh <pushkarkumarsingh1970@gmail.com> writes:\n\n> ... or to rework it in a way that preserves the reflog\n> entry while addressing the underlying concern (if there is one).\n\nI am OK as long as this patch does not come back in its current form\n;-), but it is curious what \"the underlying concern\" is.  It sounds\nlike you see some problems that need to be addressed if the current\n\"the act of resetting to the same commit is recorded in the reflog\",\nbut I am not sure what they are.\n\nThanks.\n"}]}