git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 13, 2012, 22:39 UTC
Message-ID
<7vy5pz1cjk.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20120413215316.GA19826@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 24 quoted lines
> 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.

Previous: Jonathan NiederNext: Marc Branchaud
Message 6 of 27 in “[PATCHv2] fetch: Only call a new ref a "branch" if it's under refs/heads/.”
  1. marcnarc@xiplink.comApr 13, 2012
  2. Jonathan NiederApr 13, 2012
  3. Marc BranchaudApr 16, 2012
  4. Jeff KingApr 13, 2012
  5. Jonathan NiederApr 13, 2012
  6. Junio C HamanoApr 13, 2012
  7. Marc BranchaudApr 16, 2012
  8. Jeff KingApr 16, 2012
  9. [PATCHv3] fetch: Use the remote's ref name to decide how to describe new refs.marcnarc@xiplink.com, Apr 16, 2012
  10. Jonathan NiederApr 16, 2012
  11. Junio C HamanoApr 16, 2012
  12. Marc BranchaudApr 16, 2012
  13. 0/3 fetch: Only call a new ref a "branch" if it's under refs/heads/.marcnarc@xiplink.com, Apr 16, 2012
  14. 1/3 submodules: recursive fetch also checks new tags for submodule commitsmarcnarc@xiplink.com, Apr 16, 2012
  15. 2/3 fetch: Pass both the full remote ref and its short name to update_local_ref().marcnarc@xiplink.com, Apr 16, 2012
  16. 3/3 fetch: Use the remote's ref name to decide how to describe new refs.marcnarc@xiplink.com, Apr 16, 2012
  17. Jonathan NiederApr 16, 2012
  18. Zbigniew Jędrzejewski-SzmekApr 17, 2012
  19. Jonathan NiederApr 17, 2012
  20. Zbigniew Jędrzejewski-SzmekApr 17, 2012
  21. Marc BranchaudApr 17, 2012
  22. Jonathan NiederApr 17, 2012
  23. Junio C HamanoApr 17, 2012
  24. Junio C HamanoApr 17, 2012
  25. Marc BranchaudApr 17, 2012
  26. Jeff KingApr 17, 2012
  27. Jonathan NiederApr 16, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.