summaryrefslogtreecommitdiff
path: root/t/t3409-rebase-preserve-merges.sh
diff options
context:
space:
mode:
authorLibravatar Johannes Schindelin <johannes.schindelin@gmx.de>2019-09-30 10:21:55 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-10-02 14:44:54 +0900
commit2049b8dc65e7371c56452cfda5234182d58b704e (patch)
tree50ad08a526b3ef7bd06beceb6255984b78f5af64 /t/t3409-rebase-preserve-merges.sh
parentMove git_sort(), a stable sort, into into libgit.a (diff)
downloadtgif-2049b8dc65e7371c56452cfda5234182d58b704e.tar.xz
diffcore_rename(): use a stable sort
During Git's rename detection, the file names are sorted. At the moment, this job is performed by `qsort()`. As that function is not guaranteed to implement a stable sort algorithm, this can lead to inconsistent and/or surprising behavior: a rename might be detected differently depending on the platform where Git was run. The `qsort()` in MS Visual C's runtime does _not_ implement a stable sort algorithm, and it even leads to an inconsistency leading to a test failure in t3030.35 "merge-recursive remembers the names of all base trees": a different code path than on Linux is taken in the rename detection of an ambiguous rename between either `e` to `a` or `a~Temporary merge branch 2_0` to `a` during a recursive merge, unexpectedly resulting in a clean merge. Let's use the stable sort provided by `git_stable_qsort()` to avoid this inconsistency. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t3409-rebase-preserve-merges.sh')
0 files changed, 0 insertions, 0 deletions