accessing oldest reflog entry with ref@{N}?

accessing oldest reflog entry with ref@{N}?

[SZEDER Gábor]

Hi,

after a couple of months of inactivity I recently updated my git clone
from the main repo, and later ran 'git gc', which, of course,
dutifully pruned the old reflog entries, leaving my reflogs quite
shallow:

$ git reflog master
0dbd8125 master@{0}: merge origin/master: Fast-forward
f3828dc0

Then later I had to access the previous state, which I usually do with
master@{1}, but not this time:

$ git log --oneline -1 master@{1}
fatal: Log for 'master' only has 1 entries.

Annoyed, I just copy-pasted the sha and got the job done.

However, I wonder why it didn't worked.  'git reflog' didn't print
master@{1} or any message for the oldest entry, but I can live without
that.  The sha is undoubtedly there, however, so git should know where
master@{1} points and should "Just Work", shouldn't it?


Thanks,
Gábor

Re: accessing oldest reflog entry with ref@{N}?

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

> $ git log --oneline -1 master@{1}
> fatal: Log for 'master' only has 1 entries.
>
> Annoyed, I just copy-pasted the sha and got the job done.
>
> However, I wonder why it didn't worked. 'git reflog' didn't print
> master@{1} or any message for the oldest entry, but I can live without
> that.

There lies your answer, no?

Each of the log entry records "this was before, and this is after
the change".  ref@{0} reads from the "after" field of 0-th (from the
end) entry. ref@{1} reads from the "after" field of 1-st (again from
the end) entry.  ref@{N} reads from the "after" field of N-th (again
from the end) entry.

Notice that nowhere in the above sequence we read from "before" field.

Re: accessing oldest reflog entry with ref@{N}?

[Jeff King]

On Wed, Jun 19, 2013 at 11:48:01AM -0700, Junio C Hamano wrote:

> SZEDER Gábor <szeder@ira.uka.de> writes:
> 
> > $ git log --oneline -1 master@{1}
> > fatal: Log for 'master' only has 1 entries.
> >
> > Annoyed, I just copy-pasted the sha and got the job done.
> >
> > However, I wonder why it didn't worked. 'git reflog' didn't print
> > master@{1} or any message for the oldest entry, but I can live without
> > that.
> 
> There lies your answer, no?
> 
> Each of the log entry records "this was before, and this is after
> the change".  ref@{0} reads from the "after" field of 0-th (from the
> end) entry. ref@{1} reads from the "after" field of 1-st (again from
> the end) entry.  ref@{N} reads from the "after" field of N-th (again
> from the end) entry.
> 
> Notice that nowhere in the above sequence we read from "before" field.

In general, the "before" from entry @{N} should be the same as the
"after" of @{N+1}. Of course this is not always the case for various
reasons, the most common of which I think are:

  1. Buggy scripts which do not provide a reflog reason for their call
     to git-update-ref, and therefore update the ref without writing a
     reflog entry.

  2. A git-gc will expire entries which point to unreachable objects
     much earlier, which can create "holes" in the reflog.

So it is certainly not correct to say "we do not have a master@{1}
entry, but we know that the 'before' entry of master@{0} must point to
the same thing". But it is very often a good guess. I wonder if there
should be some simple way to expose that value as an @{}-selector.
Perhaps "ref@{0.before}" or something?

-Peff