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

[Junio C Hamano <gitster@pobox.com>]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> 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....