Re: enhanced remote ref namespaces

On Wed, Aug 12, 2015 at 11:54 AM, Junio C Hamano [off-list ref] wrote:

Jacob Keller [off-list ref] writes:

quoted

quoted

Just thinking aloud, perhaps we can introduce a brand new top level
hierarchy refs/remote/$O/{heads,tags,notes,...}, and give backward
compatibility by making a moral equivalent of a symbolic link from
refs/remote/$O/heads to refs/remotes/$O/.  The true remote-tracknig
refs continue to live in refs/remotes/$O/* and old tools that do not
know the new layout would not be hurt.  New tools that want to
ignore and look only at refs/remote/$O/* can do so through the moral
equivalent of a symbolic link.  "remote remove" needs to be taught
about this single exception (i.e. "the symbolic link"), but the
places it needs to touch is limited only to two places and will not
grow.

I think this proposal makes the sense..  I'd go with something like:

refs/tracking/<origin>/(heads|tags|notes|replace|etc)/*

with a symlink from or into

refs/tracking/<origin>/heads -> refs/remotes/<origin>

I actually do not think we even need the "symlink" thing.

We can just say refs/remotes/$O has been and forever will be where
the remote-tracking branches will live.  With or without the symlink
for backward compatibility, the updated Git will need to be aware of
the two places to deal with older and newer repositories anyway.

"everything is now under refs/tracking/$O, not spread over many
unbounded number of places like refs/remotes-$foo/$O" may appear to
be cleaner but two is already not too bad and will greatly reduce
the transition pain.

Ok, so.... just have branches be in refs/remotes/$O and all new things
be in refs/tracking/$O/category

that sounds reasonable enough to me.

That still hasn't really resolved the question of how to deal with
tags, but it does solve the question of how to deal with replace and
notes refs.

Regards,
Jake