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