mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

support git 2.34.0's handling of merge conflict between annexed and non-annexed file

Browse source 
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
This commit is contained in:
Joey Hess 2021-11-22 15:40:03 -04:00
parent c49787824c
commit 5a7f253974
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 95 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/git_2.34__58___some_conflict_resolution_unit_tests_fail.mdwn
View file

@ -137,3 +137,5 @@ I'm also building select versions of git-annex for both Windows native and WSL1/
development on master. A fine piece of software it definitely is.
[[!meta author=jkniiv]]
> [[fixed|done]] --[[Joey]]

38
doc/bugs/git_2.34__58___some_conflict_resolution_unit_tests_fail/comment_3_84a9988ee5ac6fb4b8ded7aa3164846f._comment Normal file
View file

@ -0,0 +1,38 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2021-11-22T17:31:54Z"
content="""
On to the second test failure. When there's a conflict between
a symlink and a regular file, the ort resolver uses
the names `foo` and `foo~<ref>`.
(Again not using stable naming, alas), and
the files are staged in conflict, one "added by us"
and the other "added by them".
The old resolver's behavior is to leave a single file
`foo` in conflict state "both added" and containing the content of the
file; the content of the symlink is staged as added by them.
git-annex's merge conflict resolution does not deal with this well,
because it doesn't know those two files are related. So it sees
a file eg `foo~HEAD` that is in conflict, but the conflict does
not involve an annexed file. So it does not try to resolve that merge,
because resolving a merge not involving an annexed file is out of scope.
Ugh. I think something has to be done about this, making the test suite
use the old resolver is not sufficient because git-annex is supposed to
recover from this kind of merge conflict.
Bear in mind that a non-annexed file with a name like `foo~HEAD`
that is in "added by us" state can also happen when a file is modified by
us, and deleted by them. So resolving such a file by adding it makes a
decision that git-annex does not want to make about a non-annexed file.
So, it seems that to fix this, git-annex will have to somehow learn
that `foo` and `foo~<ref>` are the two sides of a merge
conflict. It would have to base that on the filenames that git uses
and the fact that one is a symlink and the other is a normal file.
Ok, done..
"""]]