On Wed, Oct 28, 2015 at 1:20 AM, Junio C Hamano <gits...@pobox.com> wrote: >> 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". > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
