From: Emily Shaffer <email@example.com>
Cc: firstname.lastname@example.org, email@example.com
Subject: BUG() during criss-cross merge with directory rename and deleted file
Date: Fri, 26 Jul 2019 15:09:28 -0700 [thread overview]
Message-ID: <20190726220928.GG113966@google.com> (raw)
As mentioned during the standup in #git-devel today, we encountered a
BUG() during certain circumstances of a criss-cross merge. Timing has
prevented me from getting the repro case together to send just yet, but
it appears that the issue is as follows:
- During a merge in a repo with fairly complicated, merge-y history,
the following BUG() is seen:
"BUG: There are unmerged index entries:
BUG: 2 baz/bar.txt
BUG: merge-recursive.c:429: unmerged index entries in
- But when the user then runs `git status` (after clearing
.git/index.lock) the directory is clean.
- The repo does not contain a 'baz/bar.txt' (although 'baz/' exists).
- In the repo's history a 'foo/bar.txt' can be found (that is the only
'bar.txt' to ever exist in the project).
Digging further shows:
- The merge had multiple closest shared ancestors (criss-cross
- Directory 'foo/' was renamed on one side to 'baz/'...
- ...and 'foo/bar.txt' was deleted on the other side.
- When the virtual ancestor is generated, the directory rename can't be
resolved and leaves a conflict.
- The virtual ancestor being written to disk is in a conflicted state.
- This causes the top-level merge to fail, printing the BUG() above
which references a 'baz/bar.txt' that never really lived there.
- If merge.directoryrenames is set to any value besides "conflict", the
merge succeeds (no BUG() generated).
This seems to have been introduced in 8c8e5bd6eb331d055aa7fa6345f6dcdadd658979
although I haven't bisected it yet.
It seems like the solution is to watch for whether we're making a
virtual ancestor during a recursive merge, and if so, to treat
merge.directoryrenames = "conflict" as "true" or "false" instead.
I plan to modify the tests added in 8c8e5bd6 to highlight this issue
(just haven't had time, and probably won't til next week), and send a
patch doing the special treatment on merge.directoryrenames.
Happy to hear other ideas folks have.
next reply other threads:[~2019-07-26 22:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-26 22:09 Emily Shaffer [this message]
2019-08-05 22:33 ` [PATCH 1/1] merge-recursive: avoid directory rename detection in recursive case Elijah Newren
2019-08-06 16:57 ` Junio C Hamano
2019-08-06 17:26 ` Elijah Newren
2019-08-06 17:49 ` Junio C Hamano
2019-08-06 17:26 ` Junio C Hamano
2019-08-06 17:29 ` Elijah Newren
2019-08-06 20:28 ` Emily Shaffer
2019-08-06 21:16 ` Elijah Newren
2019-08-06 21:54 ` Emily Shaffer
2019-08-08 11:00 ` Jeff King
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).