On Thu, Sep 17, 2015 at 10:38 PM, Matthieu Moy <[email protected]> wrote: > Junio C Hamano <[email protected]> writes: > >> Matthieu Moy <[email protected]> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
