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

[Junio C Hamano <gitster@pobox.com>]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
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.