How can I use `git reflog format` while showing it as sorted by date?

Question

I want list use git reflog format, and show it as sorted by date with (--date=relative) flag.

• git reflog --format='%C(auto)%h %<|(17)%gd %C(blue)%cr%C(reset) %gs' has following output:

$ git reflog --format='%C(auto)%h %<|(17)%gd %C(blue)%cr%C(reset) %gs'
cec94e5c HEAD@{0} 12 hours ago checkout: moving from 4ad171a16415754987475d38c0864278982f9d12 to dev
4ad171a1 HEAD@{1} 3 weeks ago checkout: moving from 9e0b5961ff88310b4ab41d90f34914f7b951ec69 to 4ad171a1
9e0b5961 HEAD@{2} 3 days ago checkout: moving from dev to 9e0b5961
cec94e5c HEAD@{3} 12 hours ago checkout: moving from 4ad171a16415754987475d38c0864278982f9d12 to dev
4ad171a1 HEAD@{4} 3 weeks ago checkout: moving from dev to 4ad171a1
cec94e5c HEAD@{5} 12 hours ago reset: moving to HEAD
cec94e5c HEAD@{6} 12 hours ago pull --rebase --autostash (finish): returning to refs/heads/dev

---

• git reflog --date=relative has following output:

$ git reflog --date=relative
cec94e5c (HEAD -> dev, origin/dev) HEAD@{3 seconds ago}: checkout: moving from 4ad171a16415754987475d38c0864278982f9d12 to dev
4ad171a1 HEAD@{11 hours ago}: checkout: moving from 9e0b5961ff88310b4ab41d90f34914f7b951ec69 to 4ad171a1
9e0b5961 HEAD@{11 hours ago}: checkout: moving from dev to 9e0b5961
cec94e5c (HEAD -> dev, origin/dev) HEAD@{11 hours ago}: checkout: moving from 4ad171a16415754987475d38c0864278982f9d12 to dev
4ad171a1 HEAD@{11 hours ago}: checkout: moving from dev to 4ad171a1
cec94e5c (HEAD -> dev, origin/dev) HEAD@{11 hours ago}: reset: moving to HEAD
cec94e5c (HEAD -> dev, origin/dev) HEAD@{11 hours ago}: pull --rebase --autostash (finish): returning to refs/heads/dev

Here when we use git reflog --date=relative could we also show the HEAD@{<Number>} corresponding to each item that matches to git commit hash.

Related: Is there a way to cause git-reflog to show a date alongside each entry?

Faceplate

Unfortunately, at least as of today, you still must pick exactly one of @<number> or @<date> as the suffix for reflog entries. There's no format directive to force one or the other, only the options to globally set whether a date comes out and if so, whether it's relative. – Marelya

How would @<date> work when when there is same dates like HEAD@{11 hours ago} on my question ; since @<number> is iterative there is not conflicting numbers – Faceplate

I don't understand that question. If the output format is {name}@{numeric suffix} you'll see HEAD@0, HEAD@1, HEAD@2, etc. The numbers are always different. If the output format is {name}@{date suffix} you'll see HEAD, HEAD@{11 hours ago}, etc.; and if two dates are the same their suffix will be the same. – Marelya

Maybe you mean: if two dates look the same, what happens if you specify HEAD@{11.hours.ago} on a command line. In that case, Git picks one of them. Which one? You don't control that, so don't use that format. (The one Git picks is determined by the code, but unless you inspect the source carefully each time—it might change with each Git release—you can't know a priori which one that will be.) Since you have the hash ID to the left, use that instead. – Marelya

I have no idea but some hash IDs are same as well for different lines :-( – Faceplate

That's perfectly normal for reflogs. If a ref referred to the same commit at different times, that hash ID will appear in that ref's reflog multiple times, once for each time that name referred to that particular commit. So, for instance, if I git switch br1; git switch br2; git switch br1 (and br1 differs from br2) then HEAD will contain the same hash ID as br1 currently contains, and HEAD's reflog will have it in there at least twice because HEAD meant commit a123456 at one point, then some other commit for br2 at some point, then back to a123456. – Marelya

Remember that a ref—and this goes for any ref name, whether it's a branch name, a tag name, a remote-tracking name, or the special name HEAD—is a way to refer to some particular commit. A branch name by definition holds the hash ID that is, we claim, the latest commit "on" that branch. Which commit is the latest? That depends on which one we want to be the latest, and that changes over time. So the reflog for a branch name contains different hash IDs over time. But sometimes we use git reset to move a name back, and then the same hash ID re-appears. – Marelya

What matters to Git are the hash IDs. What matters to humans are the commit contents, but we don't like hash IDs, they're too big and ugly and random-looking. We like names. So we have Git store hash IDs in names. Then we use the names. The names remember one hash ID at a time; the reflogs store the last however-many hash IDs that were in the name, as a log of previous values stored in that name. That's why we call them "ref-logs": logs of previous values of refs. – Marelya