On Wed, Aug 12, 2015 at 8:34 PM, Jacob Keller wrote:
> On Wed, Aug 12, 2015 at 9:10 AM, Junio C Hamano wrote:
>> Some design boundaries:
>>
>> - Moving the remote-tracking branch hierarchy from refs/remotes/$O/*
>>to refs/remotes/$O/heads/* would not fly, because it will break
>>existing
Jacob Keller writes:
> 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.
I do not think it would be a good change to add a
[remote "foo"]
fetch = refs/tags/*:refs/tracking/foo/tags/
On Wed, Aug 12, 2015 at 11:54 AM, Junio C Hamano wrote:
> Jacob Keller 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
>>
Jacob Keller 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-tra
On Wed, Aug 12, 2015 at 9:10 AM, Junio C Hamano wrote:
> Jacob Keller writes:
>
>> Recently there was some discussion about git-notes and how we do not
>> fetch notes from remotes by default. The big problem with doing so is
>> because refs/remotes/* hierarchy is only setup for branches (heads),
5 matches
Mail list logo
