Reputation: 42502
In normal ("content") conflicts git will add conflict markers to the file, making it relatively clear where and what the issue is, and more importantly usually making it impossible not to resolve the conflict if there's any sort of CI/CD (as the conflict markers will very likely make the file invalid, and are easy to search for besides).
However a "modified/delete` conflict is not one of those. That is:
In that case, the file is essentially resurrected in B. It's marked as "DU", but in a big enough merge with enough conflicts it can be hard to notice, and because it's a resurrection the file is likely valid and not used by anything, so CI are likely to pretty much ignore it.
Obviously it's a user error, but is there a way to make Git surface this issue better / more clearly rather than discovering the resurrection days or weeks later, and tracing it back to an unfortunate conflict resolution?
I tried playing with conflict styles or searching around git-config
but was not able to find anything relevant.
Full demo session:
$ git init -b A test
Initialized empty Git repository in test/.git/
$ cd test
$ echo "foo" > test.txt
$ git commit -amm
$ git add test.txt
$ git commit -amm
[A (root-commit) b1ed5e3] m
1 file changed, 1 insertion(+)
create mode 100644 test.txt
$ git branch B
$ echo "bar" >| test.txt
$ git commit -amm
[A 02a53eb] m
1 file changed, 1 insertion(+), 1 deletion(-)
$ git checkout B
Switched to branch 'B'
$ git rm test.txt
rm 'test.txt'
$ git commit -amm
[B 227d7f2] m
1 file changed, 1 deletion(-)
delete mode 100644 test.txt
$ git merge --no-ff A
CONFLICT (modify/delete): test.txt deleted in HEAD and modified in A. Version A of test.txt left in tree.
Automatic merge failed; fix conflicts and then commit the result.
$ git status -sb
## B
DU test.txt
$ git add .
$ git status -sb
## B
A test.txt
$ git commit -am "resolved"
[B 5d8a521] resolved
$ cat test.txt
bar
Upvotes: 3
Views: 59