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

Added a comment: analysis

Browse source
This commit is contained in:
http://joeyh.name/ 2014-07-08 17:52:59 +00:00 committed by admin
parent 0c4f66f0c6
commit 3dcb349409
1 changed files with 15 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
doc/bugs/Merge_involving_symlink_yields_unexpected_results/comment_4_13179e0f72026092e48c13082818ce68._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.55"
subject="analysis"
date="2014-07-08T17:52:59Z"
content="""
When resolveMerge' calls graftin to add A's file2 symlink to B's tree, it actually stages the right symlink (the non-annexed one).
However, the work tree is left as-is, so it still has the annexed symlink in it. So git status shows file2 as modified. Later syncs will commit that.
This is why the sync in A doesn't have the problem, as there things are the other way around, and git-annex makes the git-annex symlink, leaving the non-annexed symlink as-is in the work tree.
So, graftin needs to update the work tree. But it's tricky because graftin is called in 3 situations: non-symlink file, directory, and non-annexed symlink.
Interestingly, in the other 2 cases, git-merge already takes care of updating the work tree -- it deletes the annexed symlink and puts in place either the non-symlink file or the directory. It's only the the case of a merge conflict involving 2 symlinks that git merge doesn't update the tree in this way. It's nice to be able to rely on git-merge in the other 2 cases, especially the directory case (avoids having to manually check out the directory).
"""]]