Re: RefTree: Alternate ref backend

From: Shawn Pearce <spearce@spearce.org>
Date: Dec 17, 2015, 22:15 UTC
Message-ID: <CAJo=hJvwwOooPG2XUbhLZqyDMwsOa1Ba7eoA1AFLkF3BHk5V8Q@mail.gmail.com>
In-Reply-To: <xmqqk2ocbuw9.fsf@gitster.mtv.corp.google.com>

On Thu, Dec 17, 2015 at 1:57 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 24 quoted lines

> Shawn Pearce <spearce@spearce.org> 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".

Show 6 quoted lines

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