Torstein Hegge <he...@resisty.net> writes:
> 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.
--
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
