Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
replay: side-step bug when directory renames are turned off
There is a bug in the way renames are cached that rears its head when directory renames are turned off. This patch comes with a demonstration of this bug which will fail with the following message unless the rename cache is explicitly reset in `merge_check_renames_reusable()` when `merge.directoryRenames=false`: merge-ort.c:2909: 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. This was a fun, intense hunt. The solution to the riddle is that indeed, there was a stale cached rename information. The fix is easy: explicitly record the diff pair as a potential rename. Helped-by; Elijah Newren <newren@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
- Loading branch information