summaryrefslogtreecommitdiff
path: root/ref-filter.h
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2020-05-03 09:13:09 (GMT)
committerJunio C Hamano <gitster@pobox.com>2020-05-04 20:44:46 (GMT)
commit7c5045fc180ed09ed4cb5065955acddc1dd50163 (patch)
treec691f2302744fef7c1446f55dd1ec974ec1f5873 /ref-filter.h
parent76f9e569adb540a1ca1a590c512d57fce4eea878 (diff)
downloadgit-7c5045fc180ed09ed4cb5065955acddc1dd50163.zip
git-7c5045fc180ed09ed4cb5065955acddc1dd50163.tar.gz
git-7c5045fc180ed09ed4cb5065955acddc1dd50163.tar.bz2
ref-filter: apply fallback refname sort only after all user sorts
Commit 9e468334b4 (ref-filter: fallback on alphabetical comparison, 2015-10-30) taught ref-filter's sort to fallback to comparing refnames. But it did it at the wrong level, overriding the comparison result for a single "--sort" key from the user, rather than after all sort keys have been exhausted. This worked correctly for a single "--sort" option, but not for multiple ones. We'd break any ties in the first key with the refname and never evaluate the second key at all. To make matters even more interesting, we only applied this fallback sometimes! For a field like "taggeremail" which requires a string comparison, we'd truly return the result of strcmp(), even if it was 0. But for numerical "value" fields like "taggerdate", we did apply the fallback. And that's why our multiple-sort test missed this: it uses taggeremail as the main comparison. So let's start by adding a much more rigorous test. We'll have a set of commits expressing every combination of two tagger emails, dates, and refnames. Then we can confirm that our sort is applied with the correct precedence, and we'll be hitting both the string and value comparators. That does show the bug, and the fix is simple: moving the fallback to the outer compare_refs() function, after all ref_sorting keys have been exhausted. Note that in the outer function we don't have an "ignore_case" flag, as it's part of each individual ref_sorting element. It's debatable what such a fallback should do, since we didn't use the user's keys to match. But until now we have been trying to respect that flag, so the least-invasive thing is to try to continue to do so. Since all callers in the current code either set the flag for all keys or for none, we can just pull the flag from the first key. In a hypothetical world where the user really can flip the case-insensitivity of keys separately, we may want to extend the code to distinguish that case from a blanket "--ignore-case". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'ref-filter.h')
0 files changed, 0 insertions, 0 deletions