There is a bug in the way renames are cached that rears its head when
`merge.directoryRenames` is set to false; it results in the following
message:
merge-ort.c:3002: process_renames: Assertion `newinfo && !newinfo->merged.clean' failed.
Aborted
It is quite a curious bug: the same test case will succeed, without any
assertion, if instead run with `merge.directoryRenames=true`.
Further, the assertion does not manifest while replaying the first
commit, it manifests while replaying the _second_ commit of the commit
range. But it does _not_ manifest when the second commit is replayed
individually.
This would indicate that there is an incomplete rename cache left-over
from the first replayed commit which is being reused for the second
commit, and if directory rename detection is enabled, the missing paths
are somehow regenerated.
Incidentally, the same bug can by triggered by modifying t6429 to switch
from merge.directoryRenames=true to merge.directoryRenames=false.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
[en: tweaked the commit message slightly, including adjusting the
line number of the assertion to the latest version, and the much
later discovery that a simple t6429 tweak would also display the
issue.]
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
done
'
+test_expect_failure 'merge.directoryRenames=false' '
+ # create a test case that stress-tests the rename caching
+ git switch -c rename-onto &&
+
+ mkdir -p to-rename &&
+ test_commit to-rename/move &&
+
+ mkdir -p renamed-directory &&
+ git mv to-rename/move* renamed-directory/ &&
+ test_tick &&
+ git commit -m renamed-directory &&
+
+ git switch -c rename-from HEAD^ &&
+ test_commit to-rename/add-a-file &&
+ echo modified >to-rename/add-a-file.t &&
+ test_tick &&
+ git commit -m modified to-rename/add-a-file.t &&
+
+ git -c merge.directoryRenames=false replay \
+ --onto rename-onto rename-onto..rename-from
+'
+
test_done