Re: [PATCHv2] fetch: Only call a new ref a "branch" if it's under refs/heads/.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Nieder <jrnieder@xxxxxxxxx> writes:

> Jeff King wrote:
>
>> Hmm. The ref->name we are comparing here is the local side. So if I am
>> fetching a new branch "foo" from the remote into a local
>> "refs/remotes/origin/foo" tracking ref, it used to say:
>>
>>     From ../parent
>>      * [new branch]      master     -> origin/master
>>
>> Now it says:
>>
>>     From ../parent
>>      * [new ref]         master     -> origin/master
>>
>> while refs/remotes/* are not technically branches in our side, I think
>> from the user's perspective, it is true that we have fetched a branch.
>> Should we be calling refs/remotes/* branches, too? Should we be checking
>> the remote's name for the item instead of the local one?
>
> The former sounds sensible.  Then once the default refspec learns to
> fetch into separate refs/remotes/origin/heads/* and
> refs/remotes/origin/notes/* namespaces the logic could be updated to
> write [new branch] or [new note collection] according to the
> situation.

If we give 'new branch' label for this case because we store it in our
'refs/remotes/*', a natural extension of it would be to redefine the rule
to narrow it to 'refs/remotes/*/heads/*' for using 'branch' when we
introduce 'new notes collection' label to give refs we are going to store
in 'refs/remotes/origin/notes/*'.  That is consistent with the former.

If we give 'new branch' label because refs/heads/master on the originating
end is what is shown on the line, a natural extension would be to use 'new
notes collection' label when we are fetching from refs/notes/* on the
originating end, and it does not matter where we store it, either our own
refs/notes/* or refs/remotes/origin/notes/*.  That is consistent with the
latter.

There is no concensus if refs/remotes/origin/notes/* hierarchy is a good
idea or not, but your argument does not support either side between the
former or the latter anyway, so I think it is irrelevant point to raise in
this discussion.

The choice between the two really depends on what information we are
trying to convey with this label.  Are we saying "Hey, we now have a new
'branch' on our side"?  Or are we saying "We found a new 'branch' over
there"?  It is unclear and you can argue both ways. Although I personally
think it is the latter, I do not have a strong opinion either way.

I am actually fine with just saying '[new]' without indicating what kind
at all, because the label is there only to fill the space where old..new
object names are usually shown.  We don't even say "[rejected branch]",
just "[rejected]" in the same place.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]