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

Karthik Nayak [off-list ref] writes:

On Wed, Oct 28, 2015 at 1:20 AM, Junio C Hamano [off-list ref] wrote:

quoted

quoted

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".

quoted

    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.

Now these are enough bits of info, that can and needs to be
condenced into an updated log message to help future readers.

Thanks.

On Thu, Oct 29, 2015 at 3:46 AM, Junio C Hamano [off-list ref] wrote:

Karthik Nayak [off-list ref] writes:

quoted

On Wed, Oct 28, 2015 at 1:20 AM, Junio C Hamano [off-list ref] wrote:

quoted

quoted

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".

quoted

    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.

Now these are enough bits of info, that can and needs to be
condenced into an updated log message to help future readers.

Thanks.

Will update and send, thanks :)

-- 
Regards,
Karthik Nayak