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

From: Karthik Nayak <karthik.188@gmail.com>
Date: Sep 17, 2015, 18:25 UTC
Message-ID: <CAOLa=ZTn+arYr1HHA3CH+E2Sd7z9-ry=7D-QRSUM98kSKKcXdg@mail.gmail.com>
In-Reply-To: <vpqmvwlm0rt.fsf@anie.imag.fr>

On Thu, Sep 17, 2015 at 10:38 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 27 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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".

Thanks for explaining what I had in mind, Seems like the confusion is sorted, I have nothing more to add to this discussion. Junio is right, sorting by "refname" would indeed work, I was just thinking along the lines of what you're ;)

-- 
Regards,
Karthik Nayak