[1718627440]

> So, one big example is detatched HEADs: any changes you make to those, which still are contents of the repository, are not tracked in the reflog.

    $ git checkout HEAD
    $ git commit --allow-empty -m "_"
    $ git checkout master
    $ git reflog
    a91 (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: checkout: moving from b94 to master
    b94 HEAD@{1}: commit: _
    28d (origin/feature, feature) HEAD@{2}: checkout: moving from feature to @

> Even for refs, there's differences: the reflog says "ref was in state x and changed to state y" without any more details. jj's oplog keeps track of not only the state change, but the reason why: "rebased commit <sha> with these args: jj rebase -r <sha> -d trunk"

> The reflog only tracks individual refs. Say we rebase multiple commits. The reflog still just says "the head of this branch was in state x and changed to state y" but the oplog says "a rebase happened, it affected all of these commits refs in these ways," that is, it's just inherently more rich in what it tracks, and does it across all relative commits, not only the refs.

    68e HEAD@{15}: rebase (finish): returning to refs/heads/feature
    68e HEAD@{16}: rebase (pick): message #6
    7ff HEAD@{17}: rebase (pick): message #5
    797 HEAD@{18}: rebase (pick): message #4
    776 HEAD@{19}: rebase (pick): message #3
    c7d HEAD@{20}: rebase (pick): message #2
    f10 HEAD@{21}: rebase (pick): message #1
    c0d HEAD@{22}: rebase (start): checkout @~6

    a7c HEAD@{100}: rebase (reword): message ...
    3b1 HEAD@{229}: rebase (reset): '3b1' message ...
    4a4 HEAD@{270}: rebase (continue): message ...

[steveklabnik]

Oh yeah I forgot HEAD Is a ref, whoops. Duh! (My git is getting rusty at this point...)

jj still ends up keeping information in here that the reflog doesnt, but you're right that these aren't the strongest points.

[martinvonz]

One little benefit of the op log is that you can use a single `jj undo` to undo all the rebased branches/bookmarks in one go. If you have rebased many branches with `git rebase --update-refs`, you need to reset each of the branches separately AFAIK.

[1718627440]

      --update-refs, --no-update-refs
           Automatically force-update any branches that point to commits that
           are being rebased. Any branches that are checked out in a worktree
           are not updated in this way.

           If the configuration variable rebase.updateRefs is set, then this
           option can be used to override and disable this setting.

[martinvonz]

Are you saying that that text implies that the you can undo the rebase with a single command or that all the reflogs get updated atomically? Or how is it related to the comment you replied to?

[1718627440]

Oops. No the text implies that I can't read and answered to a claim which you didn't state, namely that --update-refs can only update specific refs. (This was given by another comment.)

Yes, this is something, that JJ provides and Git does not.

[1718627440]

Which, the stuff you said earlier is in the reflog?

I think Git will just gain a oplog. You just need to append a commit hash to a list before each command and implement undo as remove item and checkout. The hardest thing will be race conditions, but Git already knows how to be a database.