Karthik Nayak <karthik.188@xxxxxxxxx> writes: > On Wed, Oct 28, 2015 at 1:20 AM, Junio C Hamano <gitster@xxxxxxxxx> 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. Now these are enough bits of info, that can and needs to be condenced into an updated log message to help future readers. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html