1

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?

alper
  • 2,919
  • 9
  • 53
  • 102
  • Unfortunately, at least as of today, you still must pick exactly one of `@` or `@` 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. – torek May 26 '22 at 09:44
  • How would `@` work when when there is same dates like `HEAD@{11 hours ago}` on my question ; since `@` is iterative there is not conflicting numbers – alper May 26 '22 at 09:48
  • 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. – torek May 26 '22 at 09:58
  • 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. – torek May 26 '22 at 09:59
  • I have no idea but some hash IDs are same as well for different lines :-( – alper May 26 '22 at 10:10
  • 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`. – torek May 26 '22 at 13:11
  • 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. – torek May 26 '22 at 13:13
  • 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. – torek May 26 '22 at 13:15

0 Answers0