Some filesystems have stupid rules about characters not allowed in filenames. For example, FAT doesn't allow '?' '*' ':' etc.
The direct mode merge code lets
git merge update a temp directory with the new files from the merge, before doing its work tree update and committing. This can fail:
error: unable to create file non-rus/Dance/Dream_Dance_Vol15/CD1/09-??.mp3 (Invalid argument)
This leaves the work tree without the file, and the index knows about the file. Result is that the next time a commit is done, this file appears to have been deleted, and that is committed and propigates out. Which can be surprising.
It would probably be better if, when the working tree cannot be updated, it left the repository in some state that would not make the next commit remove anything.
Ie, direct mode should replicate this behavior:
root@darkstar:/home/joey/mnt>git init root@darkstar:/home/joey/mnt>git merge FETCH_HEAD error: unable to create file foo? (Invalid argument) fatal: read-tree failed root@darkstar:/home/joey/mnt>git status On branch master Initial commit nothing to commit (create/copy files and use "git add" to track)
Problem is, the call to
git merge can also fail due to a conflict. In that case, git-annex wants to continue with automatic conflict resolution.
So, how to detect when
git merge has skipped creating illegal filenames?
Alternatively, git-annex could learn/probe the full set of characters not allowed in filenames, and examine merges before performing them, and refuse to do anything if the merge added an illegal filename.a