summaryrefslogtreecommitdiff
path: root/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_1_8b2f7e960cf0ed043c5ad070d6fc08e2._comment
blob: a3eace0d5bd18d0f8dd8fc88d02f8423d760e5fb (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
[[!comment format=mdwn
 username="joey"
 subject="""analysis"""
 date="2015-10-15T17:30:12Z"
 content="""
git merge fails because it cannot write to these filenames.

git-annex assumes that, if git merge failed, there was a merge conflict, so
the automatic merge conflict resolution code is run. There are probably no
unmerged files in this case. So, the automatic merge conflict resolution
finds nothing to do, probably. 

However, since the automatic merge conflict resolution code ran, it now
assumes the merge has been dealt with, and proceeds to clean up, including
making a merge commit. 

The merge commit is where the file "removal" happens. It should bail out
before that point.

The best fix would be to detect that git merge has crashed early and skip
all the merge conflict resolution etc. How? git merge uses the same
exit status for this kind of crash as it does for an unresolved merge
conflict.

It could notice that there are no merge conflicts to be found, and so know
the merge failed for some other reason. However, what if there are both
merge conflicts and illegal filenames? Testing that situation, git merge
seems to always crash on creating the illegal files, before it updates
git state to reflect any merge conflicts. So, this approach seems to work.

(It could also look for .git/MERGE_HEAD, which is written after a
conflicted merge.)

----

Note that mentions of repo size etc later in this bug report don't seem to
be related to this problem.
"""]]