summaryrefslogtreecommitdiff
path: root/builtin/commit-tree.c
diff options
context:
space:
mode:
authorJohannes Schindelin <johannes.schindelin@gmx.de>2025-03-13 02:46:39 +0000
committerJunio C Hamano <gitster@pobox.com>2025-03-18 09:48:57 -0700
commita9185cc89b92caaf6fee7188e834f22a6e095aca (patch)
treeccf976e87f8d914b67fa6cb835dd772bd1eea2a8 /builtin/commit-tree.c
parent3965976edb5b8693cbecfd39ad8438eec311403b (diff)
t3650: document bug when directory renames are turned off
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>
Diffstat (limited to 'builtin/commit-tree.c')
0 files changed, 0 insertions, 0 deletions