reflog: add --operations and --historical-branch - #2448

On Thu, Oct 15, 2026, at 15:13, Harald Nordgren via GitGitGadget wrote:
> Create a better reflog. Follows the discussion in
> https://lore.kernel.org/git/akZfm-igZKeHaDST@pks.im/.
>
> "git reflog" lists every step of a rebase and every branch switch, which
> makes it hard to see what was done and on which branch. This adds two
> options to "git reflog" and "git log -g":
>
>  * --operations shows one entry per command, folding a rebase into the entry
>    that finished or aborted it, and leaves out entries that change no
>    branch.
>  * --historical-branch decorates each entry with the branch HEAD was on when
>    it was recorded.

This sounds very useful. That you rebase many commits and then the reset
points (where each one started and ended) get obscured in the reflog is
classic for me. And I think many have had the same issue. This is why I
sometimes use `ORIG_HEAD` instead, or maybe make a backup ref.

> This sounds very useful. That you rebase many commits and then the reset
> points (where each one started and ended) get obscured in the reflog is
> classic for me. And I think many have had the same issue. This is why I
> sometimes use `ORIG_HEAD` instead, or maybe make a backup ref.

Yes! I love the reflog. But I'm also endlessly confused by it.

Sometimes I'll just pick all the commits one by one and do 'git show'
on them to figure out which one to actually pick. Not a great
experience.


Harald

On Thu, Oct 15, 2026, at 17:24, Harald Nordgren wrote:
>> This sounds very useful. That you rebase many commits and then the reset
>> points (where each one started and ended) get obscured in the reflog is
>> classic for me. And I think many have had the same issue. This is why I
>> sometimes use `ORIG_HEAD` instead, or maybe make a backup ref.
>
> Yes! I love the reflog. But I'm also endlessly confused by it.
>
> Sometimes I'll just pick all the commits one by one and do 'git show'
> on them to figure out which one to actually pick. Not a great
> experience.

:)

I got a bit curious about this forced workflow now. I tried the first
terminal navigate-and-click Git tool I could think of, tig(1), and it
turns out that you can do this:

    $ tig reflog
    $ # navigate up/down j/k
    $ # See the commit message and diff with `d`

> > Sometimes I'll just pick all the commits one by one and do 'git show'
> > on them to figure out which one to actually pick. Not a great
> > experience.
>
> :)
>
> I got a bit curious about this forced workflow now. I tried the first
> terminal navigate-and-click Git tool I could think of, tig(1), and it
> turns out that you can do this:
>
>     $ tig reflog
>     $ # navigate up/down j/k
>     $ # See the commit message and diff with `d`

I don't use tig, lazygit, github desktop or vscode’s version control
extension, not because they’re not good (they probably are) but only
because I don't want to be removed from the fundamentals. I want to
feel the pain of using git :)

But that seems like an improvement, yes, thanks for pointing it out!
Good news is that git options are passed through to tig, so with this
new feature we could run:

    tig reflog --operations


Harald

On Thu, Oct 15, 2026 at 12:04 PM Harald Nordgren
<haraldnordgren@gmail.com> wrote:
>
> > This sounds very useful. That you rebase many commits and then the reset
> > points (where each one started and ended) get obscured in the reflog is
> > classic for me. And I think many have had the same issue. This is why I
> > sometimes use `ORIG_HEAD` instead, or maybe make a backup ref.
>
> Yes! I love the reflog. But I'm also endlessly confused by it.
>
> Sometimes I'll just pick all the commits one by one and do 'git show'
> on them to figure out which one to actually pick. Not a great
> experience.

Perhaps `git log -g -p` in that case? :)

-- 
D. Ben Knoble

[Apologies for replying in the wrong chain; it appears I haven't
received 3/3 yet and it's easier for me to reply to a message I have
than one I can only see in lore.]

On Thu, Oct 15, 2026 at 9:20 AM Harald Nordgren via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>   reflog: add --historical-branch to name the branch of each entry

> Teach "git reflog" and "git log -g" a "--historical-branch" option
> that decorates each entry with the branch it was made on, in place of
> the refs that point at the commit now. The name is colored like a
> branch decoration:
>
>   $ git reflog --historical-branch
>   4e5f6a7 (topic) HEAD@{0}: commit: add tests
>   1a2b3c4 (topic) HEAD@{1}: checkout: moving from main to topic
>   8c9d0e1 (main) HEAD@{2}: commit: fix typo

Notice how the "HEAD@" column is now not aligned? I find it really convient to
have fixed-width data at the front of the line so that I can visually pick out
pieces in columns.

So I'd suggest an alternat end-of-line format:

    $ git reflog --historical-branch
    4e5f6a7 HEAD@{0}: commit: add tests (topic)
    1a2b3c4 HEAD@{1}: checkout: moving from main to topic (topic)
    8c9d0e1 HEAD@{2}: commit: fix typo (main)

That might make picking out the branch name a little harder, so I suppose you
could try right before the messages?

    $ git reflog --historical-branch
    4e5f6a7 HEAD@{0}: (topic) commit: add tests
    1a2b3c4 HEAD@{1}: (topic) checkout: moving from main to topic
    8c9d0e1 HEAD@{2}: (main) commit: fix typo

or (since the "operation" prefixes" are useful)

    $ git reflog --historical-branch
    4e5f6a7 HEAD@{0}: commit: (topic) add tests
    1a2b3c4 HEAD@{1}: checkout: (topic) moving from main to topic
    8c9d0e1 HEAD@{2}: commit: (main) fix typo

? Obviously the misalignment in all the examples (except the EOL format) gets
worse when you have some short and some long branch names.

>     $ git reflog --historical-branch
>     4e5f6a7 HEAD@{0}: (topic) commit: add tests
>     1a2b3c4 HEAD@{1}: (topic) checkout: moving from main to topic
>     8c9d0e1 HEAD@{2}: (main) commit: fix typo

Thanks!

This is my favorite then.


Harald