Fix another crazy rename assertion

This fixes another special corner case that was being triggered at GitHub; the error being triggered is the same as what I submitted a fix for a few months ago, but the way it was triggered and the fix needed are different in this case. See the final commit message for details. The first two patches are just tiny cleanups I noticed while investigating the problem.

I will also note that I first came up with an alternative fix -- checking in use_cached_pairs() whether new_name was contained in the opt->priv->paths strmap, and if not, skipping to the next cached rename instead of adding it to pairs. That would also work, but it would mean that if a yet-subsequent commit after that did modify the old/file path, I think we'd have to re-detect the rename, which would hurt the effectiveness of the cached renames optimization. Simply avoiding using it in process_renames() allows it to avoid being forgotten (and since old/file is NOT modified, the upstream rename remains valid). Besides, this fix is nicely symmetrical to the check on !oldinfo, so it seems more aesthetic to me as well as helping us preserve performance.

Elijah Newren (3):
t6429: update comment to mention correct tool
merge-ort: remove debugging crud
merge-ort: fix failing merges in special corner case

 merge-ort.c                              | 31 +++++++-
 t/t6429-merge-sequence-rename-caching.sh | 93 ++++++++++++++++++++++--
 2 files changed, 114 insertions(+), 10 deletions(-)

base-commit: 4253630c6f07a4bdcc9aa62a50e26a4d466219d1
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1992%2Fnewren%2Ffix-another-crazy-rename-assertion-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1992/newren/fix-another-crazy-rename-assertion-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1992

gitgitgadget