Re: [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Sep 17, 2015, 17:08 UTC
- Message-ID
- <vpqmvwlm0rt.fsf@anie.imag.fr>
- In-Reply-To
- <xmqqeghxj8i1.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 10 quoted lines
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > >> But that's still workable: struct ref_sorting could contain a flag >> "head_first" that would be set by ref_default_sorting() and only it, and >> then read by cmp_ref_sorting. > > Hmm, I am still puzzled. "refname" atom would expand to things like > "HEAD", "refs/heads/master", etc., so I still do not see a need for > head_first option at all. "HEAD" will sort before "refs/anything" > always, no?
Ah, you mean, the alphabetic order on refname already sorts HEAD first because other refs will start with "refs/"? So, there's no need for any special case at all indeed. Nothing to teach compare_refs, it's already doing it.
However, just relying on this seems a bit fragile to me: if we ever allow listing e.g. FETCH_HEAD as a reference, then we would get
FETCH_HEAD * (HEAD detached at ...) master
which seems weird to me. But we can decide "if sorting on refname, then HEAD always comes first anyway".
-- Matthieu Moy http://www-verimag.imag.fr/~moy/