Re: RefTree: Alternate ref backend

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Dec 23, 2015, 04:59 UTC
Message-ID: <567A2A44.3050003@alum.mit.edu>
In-Reply-To: <xmqqsi2ucm60.fsf@gitster.mtv.corp.google.com>

On 12/22/2015 08:34 PM, Junio C Hamano wrote:

Show 31 quoted lines

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

You are answering "What is 'refs/' good for in the pathnames of files that store loose references?" I was asking "What is 'refs/' good for in the logical names of references?"

It would have been totally possible to make the full name of a branch be, for example, "heads/master" and nevertheless store its loose reference in "$GIT_DIR/refs/heads/master". The obvious place to store HEAD in such a scheme would have been "$GIT_DIR/refs/HEAD" while still calling it "HEAD". This could have avoided the problem that we now have with pseudo-references like FETCH_HEAD being stored directly in $GIT_DIR.

On 12/22/2015 09:56 PM, Martin Fick wrote:

Show 17 quoted lines

> On Tuesday, December 22, 2015 06:17:28 PM you wrote:
>> On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty
> <mhagger@alum.mit.edu> wrote:
>>
>> [...] Would we really be worse off if
>> references' full names were
>>
>>     HEAD
>>     heads/master
>>     tags/v1.0.0
>>     remotes/origin/master (or remotes/origin/heads/master)
>
> I think this is a bit off, because
>
>   HEAD != refs/HEAD
>
> so not quite useless.

A reference called "refs/HEAD" is not forbidden today but it's still not very useful, is it? Do you know of some system that uses reference names like this or are you just pointing out that it's theoretically possible?

Show 10 quoted lines

> But, I agree that the whole refs notation has always bugged
> me, it is quirky.  It makes it hard to disambiguate when
> something is meant to be absolute or not.  What if we added
> a leading slash for absolute references? Then I could do
> something like:
>
> /HEAD
> /refs/heads/master
> /refs/tags/v1.0.0
> /refs/remotes/origin/master

I like the idea of having a way to express "absolute" reference names. But maybe if we do so we could take a step towards deprecating "refs/" in references' logical names, by instead using the following absolute notation for the above references:

    /HEAD
    /heads/master
    /tags/v1.0.0
    /remotes/origin/master

Specifically:

* Any name of the form "/$name" for which is_pseudoref_syntax($name)
  returns true would be mapped to what we today call "$name" (e.g.,
  "/FETCH_HEAD" would be mapped to today's "FETCH_HEAD")

* Any other name of the form "/$name" would be mapped to today's
  "refs/$name".

Note that all of the absolute reference listed above, with their leading "/" removed, have the same interpretation under DWIM as they would as absolute names under my proposal (provided of course, that there is no DWIM ambiguity with other reference names).

The only disadvantage that I can see with this scheme is that there would be no "absolute" notation for a reference that currently has a full name like "refs/HEAD" (or more generally a reference currently called "refs/$name" where is_pseudoref_syntax($name) returns true). I think that is acceptable: (1) such references are probably not in wide use; (2) we wouldn't (yet) have to prohibit such references; even though there would be no absolute notation to represent them, their old-style names would still work.

If we ever decide to go further in banishing "refs/", the next step in the transition would be to disallow names like "refs/HEAD", treat the absolute reference names as the "canonical" version, and adding DWIM rules that treat a prefix "refs/" very much like a leading "/".

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu