When I git clone a repository with symlinks on a vboxsf
filesystem the symlinks all work fine, but git always say that the file has been updated, even if the change is added to the repo.
When I use it on the ext4
filesystem on root, everything works fine.
I am using a Vagrant VM on Windows. The vboxsf filesystem is the type used for a directory shared with the Windows host. It is capable of supporting symlinks (despite the underlying filesystem being on Windows).
$ git --version
git version 1.7.9.5
$ mount
--- snipped ---
vagrant-root on /vagrant type vboxsf (uid=1000,gid=1000,rw)
$ git init repo
Initialized empty Git repository in /vagrant/dev/repo/.git/
$ cd repo
$ echo foo > foo
$ ln -s foo bar
$ cat bar
foo
$ ls -l
total 1
lrwxrwxrwx 1 vagrant vagrant 0 Sep 12 17:34 bar -> foo
-rwxrwxrwx 1 vagrant vagrant 4 Sep 12 17:34 foo
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# bar
# foo
nothing added to commit but untracked files present (use "git add" to track)
$ git add --all
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: bar
# new file: foo
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: bar
#
$ git commit -m "1st commit"
[master (root-commit) ec99b71] 1st commit
2 files changed, 2 insertions(+)
create mode 120000 bar
create mode 100644 foo
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: bar
#
no changes added to commit (use "git add" and/or "git commit -a")
I still get the same behaviour after upgrading to git v1.8.4
So it seems that git creates the symlinks properly during a clone, but then it fails to handle them correctly when the files are being committed.
Are there any git settings that will help me persuade git that my strange fs does do symlinks?
Update
I have managed to get git working (for my purposes) on a virtualbox shared folder filesystem (vboxsf
) with a Windows host.
- Run Virtual Box as Administrator - that allows symlinks to be created on the host filesystem and therefore allows the guest filesystem to create and use symlinks
- Use
git update-index --assume-unchanged
for each symlink. This allows other files to be committed, withoutgit
thinking that the symlinks have been changed.
Problems
- The symlinks don't work in Windows (I don't think - though I don't need to use them there, so haven't tried much)
- In order to create new symlinks or edit old ones, I have to do it on an ext4 volume.