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

Re: [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 17, 2015, 15:15 UTC
Message-ID
<xmqqh9mtkrg0.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<vpqpp1hqgcd.fsf@anie.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 13 quoted lines
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>> So either we could introduce a new atom for sorting something like
>> `branch_sort` which uses the FILTER_REFS_(DETACHED_HEAD | BRANCHES |
>> REMOTES)
>
> I don't think you need a new atom. You can just change the sorting
> function to consider that detached HEAD is always first, and when
> comparing two non-detached-HEAD branches, use the atom supplied by the
> user.
>
> That would mean the detached HEAD would be displayed first regardless of
> --sort (which is the case right now).

I am a bit fuzzy about this. I do not understand why Karthik thinks a new atom is necessary in the first place, and I do agree that the best way to go would be to teach the sort function to do "the right thing", but I am not sure why it has to be "regardless of --sort".

In the original for-each-ref (before it was butchered^W updated with ref-filter), we grab refs and sort with default_sort() when "--sort" is not given. When --sort is given, we just use atoms to compare.

I do not think ref-filter broke that pattern, and as long as it kept that pattern, I do not think the solution has to be more than just "teach that default_sort() function, which sorts by refname, to always show HEAD first". When you throw HEAD into the mix, instead of grabbing only from refs/*, you can still give that set to a sorting function, which by default puts "HEAD" before others (just like the sorting function for "branch -a" by default puts local before remote-tracking), and you are done, no?

When the user does give a custom --sort criteria, the logic in default_sort() would not kick in, so there is no need for special casing for "HEAD" like the code I questioned in this thread.

What am I missing?
> Introducing a new atom would mean that "git branch --sort authorname"
> would not use this new atom, hence the HEAD would be sorted like the
> others.
I think that is exactly what people would expect.

Perhaps a slightly tricky would be "git branch -a --sort refname". If you have HEAD, refs/heads/master, and refs/remotes/origin/master, I'd expect that it would sort these in that order purely because that is the textual/ascii sort order of the FULL refname.

And then at the presentation level you would strip refs/heads and refs/remotes from local and remote-tracking branches, just like "git branch -a" output has always done, from the sorted result when showing.

"git branch -a --sort refname:short" would sort using HEAD vs master vs origin/master in the above example and would end up mixing loal and remote-tracking together, but that is what the user is asking for, and the user deserves to get what s/he asked for.

Somewhat confused....
Previous: Matthieu MoyNext: Matthieu Moy
Message 18 of 38 in “port the filtering part of branch.c to use ref-filter APIs”
  1. 0/8 port the filtering part of branch.c to use ref-filter APIsKarthik Nayak, Sep 13, 2015
  2. 1/8 branch: refactor width computationKarthik Nayak, Sep 13, 2015
  3. Matthieu MoySep 13, 2015
  4. Karthik NayakSep 13, 2015
  5. Matthieu MoySep 13, 2015
  6. 2/8 branch: bump get_head_description() to the topKarthik Nayak, Sep 13, 2015
  7. 3/8 branch: roll show_detached HEAD into regular ref_listKarthik Nayak, Sep 13, 2015
  8. Matthieu MoySep 13, 2015
  9. Karthik NayakSep 13, 2015
  10. Eric SunshineSep 13, 2015
  11. Eric SunshineSep 13, 2015
  12. Karthik NayakSep 14, 2015
  13. Matthieu MoySep 14, 2015
  14. Junio C HamanoSep 14, 2015
  15. Karthik NayakSep 16, 2015
  16. Karthik NayakSep 17, 2015
  17. Matthieu MoySep 17, 2015
  18. Junio C HamanoSep 17, 2015
  19. Matthieu MoySep 17, 2015
  20. Junio C HamanoSep 17, 2015
  21. Matthieu MoySep 17, 2015
  22. Junio C HamanoSep 17, 2015
  23. Karthik NayakSep 17, 2015
  24. 4/8 branch: move 'current' check down to the presentation layerKarthik Nayak, Sep 13, 2015
  25. Matthieu MoySep 13, 2015
  26. Karthik NayakSep 13, 2015
  27. 4/8 branch: move 'current' check down to the presentation layerKarthik Nayak, Sep 13, 2015
  28. 5/8 branch: drop non-commit error reportingKarthik Nayak, Sep 13, 2015
  29. Junio C HamanoSep 14, 2015
  30. Karthik NayakSep 16, 2015
  31. 6/8 branch.c: use 'ref-filter' data structuresKarthik Nayak, Sep 13, 2015
  32. Matthieu MoySep 13, 2015
  33. Karthik NayakSep 13, 2015
  34. Matthieu MoySep 13, 2015
  35. 6/8 branch.c: use 'ref-filter' data structuresKarthik Nayak, Sep 13, 2015
  36. Karthik NayakSep 13, 2015
  37. 8/8 branch: add '--points-at' optionKarthik Nayak, Sep 13, 2015
  38. 7/8 branch.c: use 'ref-filter' APIsKarthik Nayak, Sep 13, 2015

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.