accessing oldest reflog entry with ref@{N}?
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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: accessing oldest reflog entry with ref@{N}?
SZEDER Gábor sze...@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.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: accessing oldest reflog entry with ref@{N}?
On Wed, Jun 19, 2013 at 11:48:01AM -0700, Junio C Hamano wrote:
SZEDER Gábor sze...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
