Re: RefTree: Alternate ref backend
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 22, 2015, 19:34 UTC
- Message-ID
- <xmqqsi2ucm60.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <CAJo=hJswuPdLT0KtGdf_=UGxD7-5NjGk2mwFjRU=uYb-Su-y+A@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
Show 22 quoted lines
> On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Shawn Pearce <spearce@spearce.org> writes:
>>
>>>> But really, aside from slightly helping
>>>> disambiguate references from paths in the command line, what is it good
>>>> for?
>>>
>>> Nothing really; today refs/ prefix is used to encourage to the tools
>>> that you really meant refs/heads/master and not
>>> refs/heads/heads/master or some other crazy construct. You can thank
>>> the DWIMery inside the ref rev parse logic for needing this.
>>
>> Aren't you two forgetting one minor thing, though?
>>
>> A layout without refs/, i.e. $GIT_DIR/{heads,tags,...}, will force
>> us to keep track of where the tips of histories are anchored for
>> reachability purposes, every time you would add a new hierarchy
>> (e.g. $GIT_DIR/changes)--and those unfortunate souls who run a
>> slightly older version of Git that is unaware of 'changes' hierarchy
>> would weep after running "git gc", no?
>
> You still store them under refs/Well I know; the comment was merely a reaction to the exchange between you two, "What is refs/ good for?", "Nothing really".
You'd benefit by having "refs/" that is known to contain all the anchoring points for reachability without knowing what subhierarchy it may contain in the future, that is what it is good for.