Persuading git to handle symlinks correctly on vbo

2019-09-16 11:18发布

问题:

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.

  1. 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
  2. Use git update-index --assume-unchanged for each symlink. This allows other files to be committed, without git thinking that the symlinks have been changed.

Problems

  1. 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)
  2. In order to create new symlinks or edit old ones, I have to do it on an ext4 volume.

回答1:

Based on the mount output are using default synced folder, which is VirtualBox's vboxsf.

Not sure if you are aware that vboxsf lacks support for symbolic / hard links, which will potentially cause problems using git. see the ticket #818 here, it is still not fixed.

So I would avoid using vboxsf, use sshfs or NFS instead to share files and directories between host and guest.

NOTE: sshfs is pretty handy, we will be able to mount remote path via SSH and use them as if they were local. I haven't heard of git issues like vboxsf (but could still be).

Quick example:

mount remote ssh directory as sshfs => sudo sshfs user@host:~user /mnt/sshfs

unmount sshfs => sudo fusermount -u /mnt/sshfs