Re: [PATCH v2 0/2] Git's rename detection requires a stable sort

"Johannes Schindelin via GitGitGadget" [off-list ref]
writes:

With the en/merge-recursive-cleanup patches already having advanced to next,
the problem I discovered when rebasing Git for Windows' branch thicket
becomes quite relevant now: t3030.35 fails consistently in the MSVC build &
test (this part of the Azure Pipeline will be upstreamed later).

The solution: use a stable sort.

Note: this patch series is based on top of en/merge-recursive-cleanup.

Changes since v1:

 * The function was renamed to git_stable_qsort(), as per Junio's
   suggestion.

Johannes Schindelin (2):
  Move git_sort(), a stable sort, into into libgit.a
  diffcore_rename(): use a stable sort

 Makefile                         |  2 +-
 compat/mingw.c                   | 11 +++--------
 diffcore-rename.c                |  2 +-
 git-compat-util.h                |  9 ++++++---
 compat/qsort.c => stable-qsort.c |  6 +++---
 5 files changed, 14 insertions(+), 16 deletions(-)
 rename compat/qsort.c => stable-qsort.c (89%)

Thanks.  All looked sensible.

 1:  1202809db7 < -:  ---------- Move git_sort(), a stable sort, into into libgit.a
 -:  ---------- > 1:  8a99008a64 Move git_sort(), a stable sort, into into libgit.a

This is where the current range-diff could be improved to shine
more.  If it were allowed to compute a pairwise diff with rename
detection, readers would be able to see that qsort.c from version 1
is renamed to stable-qsort.c in version 2 with minimum adjustment of
one function name.