Re: [PATCH v3] ref-filter: fallback on alphabetical comparison

From: Karthik Nayak <karthik.188@gmail.com>
Date: Oct 28, 2015, 18:55 UTC
Message-ID: <CAOLa=ZSF5bJocJkMG70x0kTaU139pj0-ONypC=V2Tdnu3yQtow@mail.gmail.com>
In-Reply-To: <xmqq7fm8ozu9.fsf@gitster.mtv.corp.google.com>

On Wed, Oct 28, 2015 at 1:20 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

>> Hence, fallback to alphabetical comparison based on the refname
>> whenever the other criterion is equal. Fix the test in t3203 in this
>> regard.
>
> It is unclear what "in this regard" is.  Do you mean this (I am not
> suggesting you to spell these out in a very detailed way in the
> final log message; I am deliberately being detailed here to help me
> understand what you really mean)?
>
>     A test in t3203 was expecting that branch-two sorts before HEAD,
>     which happened to be how qsort(3) on Linux sorted the array, but
>     (1) that outcome was not even guaranteed, and (2) once we start
>     breaking ties with the refname, "HEAD" should sort before
>     "branch-two" so the original expectation was inconsistent with
>     the criterion we now use.
>

Exactly what you're saying, they happened to have the same objectsize. Hence sorting them would put them together, but since we compare the refname's the "HEAD" ref would come before "branch-two".

Show 6 quoted lines

>     Update it to match the new world order, which we can now depend
>     on being stable.
>
> I am not sure about "HEAD" and "branch-two" in the above (it may be
> comparison between "HEAD" and "refs/heads/branch-two", for example).
>

It actually is, we consider "refs/heads/branch-two rather then the shortened version of this. It makes sense to classify refs this way, even though this was a side effect of this commit.

-- 
Regards,
Karthik Nayak