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

more

Browse source
This commit is contained in:
Joey Hess 2020-09-06 10:51:23 -04:00
parent 842afa71ab
commit 13fdba133f
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 24 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
doc/bugs/new_merge.directoryRenames_behavior_breaks_sync_merge_conflict_resolution.mdwn
View file

@ -9,23 +9,33 @@ When this happens during a git-annex sync, the result is:
With the .variant file checked in, but the other one not checked in. With the .variant file checked in, but the other one not checked in.
Which is problimatic both because the file does not get checked in, and because Which is problimatic both because the file does not get checked in, and
if this is a merge conflict at all (I disagree with git that it should be, because if this is a merge conflict at all (I disagree with git that it
didn't used to be), it's a conflict between x/foo/bar.ext and y/bar.ext and so should be, didn't used to be), it's a conflict between x/foo/bar.ext and
git-annex sync should presumably make those two into .variant files, not 2 y/bar.ext and so git-annex sync should presumably make those two into
files in the same directory. .variant files, not 2 files in the same directory. Although, it might be
better for git-annex not to make variant files at all in this situation,
since both files have the same content.
Although, it might be better for git-annex not to make variant files at all in The worse problem, perhaps, is that git-annex sync succeeds and if the user
this situation, since both files have the same content. was not expecting this behavior, it can seem like their file has been lost,
because it was moved to a directory they did not move it to!
git merge is relying on this being a merge conflict for the user to
see the error message and know where it renamed their file to, but this is
counter to sync's desire to avoid merge conflicts for users who are not
able to deal with that complication.
This new git feature does have a config (after not for a while), This new git feature does have a config. Set merge.directoryRenames=false to
set merge.directoryRenames=false to disable it. One option would be for sync to disable it. Or, merge.directoryRenames=true will avoid it being treated as
just set that. But if the user has enabled that option, sync should probably a merge conflict. (The config was added in 2.22, while git started doing
deal with the consequences, if at all possible. this in 2.18. Annoyingly, Debian stable shipped git 2.20 so produces conflicts
with no way to turn it off.) One option would be for sync to set one
of the two if it's not set (probably =false), and if it is set to =conflict
(or the git version lacks the config), to deal with the conflict.
Based on git commit 8c8e5bd6eb331d055aa7fa6345f6dcdadd658979, Based on git commit 8c8e5bd6eb331d055aa7fa6345f6dcdadd658979,
it uses a higher than usual stage level in the index in this case, it uses a higher than usual stage level in the index for the conflict
so it might be possible for git-annex to use that to detect it and handle it produced by case, so it might be possible for git-annex to use that
specially. to detect it and handle it specially.
--[[Joey]] --[[Joey]]