Re: RefTree: Alternate ref backend

On Tuesday, December 22, 2015 06:17:28 PM you wrote:

On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty

[off-list ref] wrote:

At a deeper level, the "refs/" part of reference names is
actually pretty useless in general. I suppose it
originated in the practice of storing loose references
under "refs/" to keep them separate from other metadata
in $GIT_DIR. But really, aside from slightly helping
disambiguate references from paths in the command line,
what is it good for? 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.

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 don't like that plumbing has to do a dance to guess at
expansions, how many tools get it wrong (do it in different
orders, miss some expansions...).  With an absolute
notation, plumbing could be built to require absolute
notations, giving more predictable interpretations when
called from tools.

This is a long term idea, but it might make sense to
consider it now just for the sake of storing refs, it would
eliminate the need for the ".." notation for "refs/..HEAD".

Now if we could only figure out a way to tell plumbing that
something is a SHA, not a ref? :)

-Martin

--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation