Re: enhanced remote ref namespaces

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