On Wed, Aug 12, 2015 at 11:54 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jacob Keller <jacob.keller@xxxxxxxxx> 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.
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html