Re: git checkout --orphan skips reflogging

On Wed, Sep 14, 2011 at 5:04 AM, Junio C Hamano [off-list ref] wrote:

Dmitry Ivankov [off-list ref] writes:

quoted

In short, git checkout --orphan doesn't write
HEAD_sha1 -> 00000
entry to logs/HEAD, while git-comit will write
00000 -> new_orphan_HEAD_sha1
entry. And then reflog backward walk will stop on 000 -> entry and
won't see earlier history.

Funny. From the point of view of the _current_ branch, it sort of makes
sense to stop the traversal at that point, but I agree for HEAD reflog
that records branch switching, the traversal should not stop.

I am not sure if recording 0{40} after --orphan is the right thing to do
either (for that matter, I do not necessarily think running --orphan is a
sane thing to do, but that is a separate issue).

In fact, my purpose is more like finding out what branches I were recently
on, most of the time even what branches I've updated recently. So, being
able to see chronologically (by ref modification time) ordered list of refs
may be a better way (than git log -g --decorate).

quoted

Isn't  it also a bug in reflog walking that we rely on each old_sha1
being new_sha1 of a previous entry?

I am not all that familiar with the reflog walking (which is admittedly a
bolted-on hack that injects commits with fake ancestry) code, but I think
it assumes the old sha1 field on the current entry matches the new sha1
field on the previous entry, and we could change it to be a bit more
robust.

The attached patch _may_ (I didn't even compile test it) remove the
dependency on osha1[] and make the code consistently use nsha1[], but I
think stopping at the 0{40} is pretty much fundamental in the revision
walking machinery the reflog walking code is piggy-backing on, and I do
not think this patch would change that.

The patch compiles fine, and walks past osha1 == 0{40}. Probably osha1
becomes completely hidden from the walking machinery, and since nsha1 is
never 0{40} (for now) whole history is walked.