From: Matt Hunter Date: Tue, 30 Jun 2026 09:23:22 GMT Subject: Re: [PATCH v5 0/4] history: add squash subcommand to fold a range Message-ID: In-Reply-To: On Tue Jun 30, 2026 at 3:19 AM EDT, Harald Nordgren wrote: >> This is probably a larger question, since (according to the man page) it >> affects the other 'git history' commands as well. When I run >> 'git history ...' and discover that I made a mistake after inspecting >> the results, is there a fool-proof way to undo the change and return to >> the previous state? My first thought was to run 'git reset --hard ...', >> but the default behavior of --update-refs (moving other branches) can >> make this more complicated. > > This is a larger question: But I would love to have a reflog that is > more human-centered. When e.g. rebasing a series with N commits, it's > very tricky in the reflog to find what was the state before that. > > I feel like branch switching is given too much space in the reflog, > since it's not a destructive action, I don't care about it. I share these headaches to an extent. When dealing with the first problem (seeing an atomic entry in the reflog), I usually look at the branch's own reflog instead of HEAD's But my question is about doing a comprehensive reset from a botched operation. If any history operation updates branch refs besides the current one. I don't think there's an obvious way to see which other ones were affected, and a naive 'git reset --hard my-branch@{1}' leaves them pointed at unwanted commits. Is this right? tangent: I'm pretty sure that git-status relies on checkout / branch switching reflog entries in order to know which tag your detached HEAD started from, eg: when it says something like HEAD detached from v2.55.0-rc2 nothing to commit, working tree clean > > And when handling multiple commits in on go (squashing, rebasing), I > would love to see a visual hierarchy (with indentation for sub-steps) > instead of treating each action as equally important when it isn't. Sounds compelling!