On case-insensitive filesystems, git-merge deletes files that were
recapitalized in another branch if rename detection fails.
To repro: Run this script with git 1.8.4 on a case-insensitive filesystem. It
repros for me on the default HFS filesystem on OS X 10.8, and also on Win7 NTFS.
# create git repo
rm -rf caps
git init caps
git config --get core.ignorecase
# commit empty file called "file"
echo file > file
git add .
git commit -am "initial commit"
# create branch called "branch"
git branch branch
# rename "file" to "File"
# using --force per http://stackoverflow.com/questions/6899582
git mv --force file File
echo "completely different content" > File
git commit -am "renamed to File"
# switch to branch, make a non-conflicting commit
git checkout branch
echo newfile > newfile
git add .
git commit -am "branch commit"
# merge master into branch, commit merge
git merge --verbose --commit --no-edit master
Actual: At the end of the script, the renamed File has been deleted by
git-merge. "ls: File: No such file or directory" According to git-status, the
deletion is not yet staged.
Expected: There should be no untracked changes at the end of this script. The
script runs as expected on Linux or case-sensitive HFS.
P.S. On case-insensitive HFS, git-init will automatically set core.ignorecase
to true. For the sake of the experiment, I also tried setting core.ignorecase
to false in the test repository.
When I did that, I was unable to even checkout the "branch" branch without
using --force. ("The following untracked working tree files would be
overwritten by checkout: file" But git-status reported no untracked changes.)
And then, once I did use force to switch to the branch, I was unable to merge
from master at all. ("The following untracked working tree files would be
overwritten by merge: File" But again, git-status reported no untracked
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html