Re: What's cooking in git.git (Nov 2013, #01; Fri, 1)

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 4, 2013, 18:07 UTC
Message-ID: <xmqq4n7s11o8.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20131103191533.GC7462@pvv.ntnu.no>

Torstein Hegge <hegge@resisty.net> writes:

Show 16 quoted lines

> On Fri, Nov 01, 2013 at 15:52:06 -0700, Junio C Hamano wrote:
>> * th/reflog-annotated-tag (2013-10-28) 1 commit
>>   (merged to 'next' on 2013-11-01 at 8b154cc)
>>  + reflog: handle lightweight and annotated tags equally
>> 
>>  "git log -g $annotated_tag", when there is no reflog history, should
>>  have produced a single output entry (i.e. the ref creation event),
>>  but instead showed the history leading to the tag.
>
> This isn't really what th/reflog-annotated-tag does, 
> "git log -g $annotated_tag" now produces no output.
>
> Is the proper behavior to output the ref creation event? In that case,
> should the same happen for lightweight tags?
>
> Or am I missing something related to "when there is no reflog history"?

I actually meant, by "no reflog history", "created once and then never updated".

But I think we first need to see if you are testing the right thing.

In a freshly created empty directory, do this:

    $ git init
    $ git commit --allow-empty -m initial
    $ git tag test master
    $ git tag -a -m 'anno' anno master
    $ find .git/logs/ -ls

For me, this does not give me any log for tags (as expected, actually). To have reflgos for these two tags, we need to do this instead (you can do these, continuing from the above):

    $ git tag -d test anno
    $ mkdir .git/logs/refs/tags
    $ >.git/logs/refs/tags/test
    $ git tag test master
    $ >.git/logs/refs/tags/anno
    $ git tag -a -m 'anno' anno master
    $ find .git/logs/ -ls
    $ grep . .git/logs/refs/tags/* .git/logs/refs/heads/*

The last one shows that we now have one reflog entry each for our lightweight and annotated tags, and the master branch also has one reflog entry. Now we can really try things out.

    $ git log -g master
    $ git log -g test
    $ git log -g anno

The first two should obviously show the same, but now I think about it, I am not sure what the last one should produce. If we further did this:

    $ git tag -f -a -m 'annotree' anno master^{tree}

what should "git log -g" show?

After all, "log -g" (and hence "reflog") takes over the usual history walking machinery and overrides it with a hack that assumes that any objects it would see in the reflog entries are commits (at least, it assumes they can be formatted with the usual codepath to pretty-print commits). There is no way for the current code (with the patch under discussion, that lifts "we deal only with commits") to magically work with a tag that points at a tree or a blob, like this last example.

I am afraid that merging that single-liner patch was a mistake. To fix the funkiness of showing "log -g" on tags, we need a lot more than that.

Will kick the topic back to 'pu' (or at least, during this feature freeze period, will backburner it and not let it graduate out of 'next').

Thanks.