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". -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
