Re: enhanced remote ref namespaces

[Junio C Hamano <gitster@pobox.com>]

Jacob Keller <jacob.keller@gmail.com> writes:

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