support git 2.34.0's handling of merge conflict between annexed and non-annexed file
authorJoey Hess <joeyh@joeyh.name>
Mon, 22 Nov 2021 19:40:03 +0000 (15:40 -0400)
committerJoey Hess <joeyh@joeyh.name>
Mon, 22 Nov 2021 20:10:24 +0000 (16:10 -0400)
commit5a7f25397439374325ea577bc6874e7e76ccb3a4
tree10d3db9cce3fc14e3d7c62c5b67e6b096f1c4fa9
parentc49787824c219db8d6c31c712a2bdbd71e26e758
support git 2.34.0's handling of merge conflict between annexed and non-annexed file

This version of git -- or its new default "ort" resolver -- handles such
a conflict by staging two files, one with the original name and the other
named file~ref. Use unmergedSiblingFile when the latter is detected.

(It doesn't do that when the conflict is between a directory and a file
or symlink though, so see previous commit for how that case is handled.)

The sibling file has to be deleted separately, because cleanConflictCruft
may not delete it -- that only handles files that are annex links,
but the sibling file may be the non-annexed file side of the conflict.

The graftin code had assumed that, when the other side of a conclict
is a symlink, the file in the work tree will contain the non-annexed
content that we want it to contain. But that is not the case with the new
git; the file may be the annex link and needs to be replaced with the
content, while the annex link will be written as a -variant file.

(The weird doesDirectoryExist check in graftin turns out to still be
needed, test suite failed when I tried to remove it.)

Test suite passes with new git with ort resolver default. Have not tried it
with old git or other defaults.

Sponsored-by: Noam Kremen on Patreon
Annex/AutoMerge.hs
CHANGELOG
Git/LsFiles.hs
doc/bugs/git_2.34__58___some_conflict_resolution_unit_tests_fail.mdwn
doc/bugs/git_2.34__58___some_conflict_resolution_unit_tests_fail/comment_3_84a9988ee5ac6fb4b8ded7aa3164846f._comment [new file with mode: 0644]