On Thu, Dec 17, 2015 at 1:57 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Shawn Pearce <spearce@xxxxxxxxxxx> writes:
>
>> For example, recent git.git has a structure like this:
>>
>> $ git ls-tree -r refs/txn/committed
>> 120000 blob 22e42fc826b437033ca444e09368f53a0b169322 ..HEAD
>> 160000 commit 1ff88560c8d22bcdb528a6629239d638f927cb96 heads/maint
>> 160000 commit f3adf457e046f92f039353762a78dcb3afb2cb13 heads/master
>> 160000 commit 5ee9e94ccfede68f0c386c497dd85c017efa22d6 heads/next
>> 160000 commit d3835d54cffb16c4362979a5be3ba9958eab4116 heads/pu
>> 160000 commit 68a0f56b615b61afdbd86be01a3ca63dca70edc0 heads/todo
>> ...
>> 160000 commit 17f9f635c101aef03874e1de1d8d0322187494b3 tags/v2.6.0
>> 160000 commit 5bebb9057df8287684c763c59c67f25f16884ef6 tags/v2.6.0-rc0
>> 160000 commit 16ffa6443e279a9b3b63d7a2bebeb07833506010 tags/v2.6.0-rc0^{}
>> ...
>> 160000 commit be08dee9738eaaa0423885ed189c2b6ad8368cf0 tags/v2.6.0^{}
>>
>> Tags are stored twice, to cache the peel information for network advertisements.
>
> The object 17f9f635 is not a "commit" but is a "tag". It is
> somewhat unfortunate that "ls-tree -r" reports it as a commit; as
> the command (or anything that deals with a gitlink) is not allowed
> to look at the actual object, it is the best it could do, though.
Yes; thus far GITLINK is only used for commits in submodules so its
reasonable for it to just hardcode the text "commit".
> The "..HEAD" hack looks somewhat ugly. I can guess that the
> reasoning went like "if we stored these in the most natural way, we
> always need a top-level tree that hold two and only two entries,
> HEAD and heads/, which would require us one level of tree unwrapping
> to get to most of the refs" and "HEAD is the only oddball that is
> outside refs/ hierarchy,
Correct.
> others like MERGE_HEAD are ephemeral and
> for the purpose of Gerrit that does not even do working tree
> management, those things that are not necessary in order to manage
> only the committed state can be omitted.", but still...
Yes. I was mostly looking at this from a bare repository server
perspective, not a user working tree. On a bare repository you
probably don't have those special refs like MERGE_HEAD, FETCH_HEAD,
etc.
They could be stored as "..MERGE_HEAD", if you had to. But only HEAD
really matters to hint to clients what to checkout by default on
clone.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html