Sergey Organov <sorganov@xxxxxxxxx> writes: >> But then if you do >> >> $ git reflog expire --expire=now refs/heads/newbranch >> $ git commit --allow=empty -m two >> $ git show -s newbranch@{1} >> ... >> And it is unintuitive. It is understandable to the users that all >> the ref history before "reflog expire" is lost---it was what the end >> user asked Git to do. But after creating one commit on the state >> (or do anything else that moves the ref) and finding it regrettable, >> "git reset --hard @{1}" should be a viable way to recover from the >> mistake made _after_ the reflog entries were expired. And the expiration does not have to be --expire=now; what happens more often is when I expire entries older than (say) a week, the reflog for a topic branch that hasn't seen any activity may become empty. Then I "git am" the new round on the same base, compare and then update, perhaps like so: ... git reflog expire has emptied the log for so/topic ... $ git checkout so/topic $ git log master.. ;# remind myself what the previous round had $ git checkout master... ;# detach HEAD at the previous base $ git am -s ./+so-v2-topic ;# apply $ git range-diff @{-1}... ;# compare $ git checkout -B so/topic Now, I'm used to see this work after the above: $ git range-diff @{1}... ;# compare again just to be sure but because there is only one entry in the reflog, which was created when the last "checkout -B" updated the so/topic branch, "there is only one entry" error kicks in. > Makes sense. The first solution that comes to mind is immediately record > current state after "reflog expire", so that there will be 2 entries for > the case in question. Perhaps. Or we could change the lookup side to use the value of the ref itself when asked for @{0}, and use the "old" side of the only entry when asked for @{1}. That way, we do not need to play games with an artificial entry at all, which may be a better solution. I dunno.