Re: git checkout --orphan skips reflogging

From: Dmitry Ivankov <divanorama@gmail.com>
Date: Sep 14, 2011, 11:55 UTC
Message-ID: <CA+gfSn8fHYEdQHzamyWqQ0zCvMCTdnVnJM_dxaq9D_hjq7x1zQ@mail.gmail.com>
In-Reply-To: <7vaaa8vyc8.fsf@alter.siamese.dyndns.org>

On Wed, Sep 14, 2011 at 5:04 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> Dmitry Ivankov <divanorama@gmail.com> writes:
>
>> 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).

Show 14 quoted lines

>> 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.