Share Git repository between Windows VM and Linux host

Question

I work mostly on Linux, but I also have a Windows VM, mostly to run unit tests on Windows.

In Linux I have a Git repository, which is accessible from the Windows VM using a VirtualBox Shared Folder. I don't use Git on Windows, except for our build system, which records the current Git hash to include it in the executable (running git describe --always --dirty).

Now, every time I use Git on either Linux or Windows and then again on the other system, it takes a while. For example:

  Linux$ git status
  Linux$ git status # fast (<1s)
Windows$ git status # takes a few dozen seconds
Windows$ git status # fast (<1s)
  Linux$ git status # takes a few seconds
  Linux$ git status # fast (<1s)

Is there anything I can do to prevent this from happening? I'd be fine turning off Git features on Windows, as it only needs to get a hash. However I can't change how this hash is obtained, as this is deep in the build system. I also do not want to have separate repositories on Linux and Windows and commit/push from one another, as this would result in an ever bigger overhead.

Linux git version: 2.11.0.

Windows git version: 2.14.1.windows.1.

Cathodoluminescence

I imagine, during that time, your VirtualBox is syncing data between your systems. – Egocentrism

"I can't change how the has is obtained"... Well, ok, but how is the hash obtained? – Hasp

I would recommend using a 3rd party such as github or bitbucket to host your repository, and clone down the repository separately on each. git status would be immediate as it only needs to go to a local disk. Sharing a single repo via shared / network storage is not really the intended use case for git. – Breastsummer

@MaxFriederichs I already have a Git server, but I explicitly say in the question that committing and pulling every time I need to run tests would have an even bigger overhead. – Cathodoluminescence

@MarkAdelsberger I've edited the question. – Cathodoluminescence

Answer 1

What you are seeing here is how effective Git's index is when used as a cache.

Along with all the other stuff it does, Git's index acts as a cache of data about the work-tree to speed up file system operations—well, really, to skip file system operations, if possible. It does this by recording statistics about files (and, secretly, directories, even though Git does not actually store directories). This cache is only valid if a number of conditions hold. If not, Git has to do expensive file system operations on the work-tree, which as you have seen, take literally seconds of time on Linux, and are even slower on Windows.

Shared folders violate the cache assumptions. In particular, one of the items in the index is the path of the work-tree, and the path is different inside the Linux system than it is in the Windows VM. (This would generally be true regardless of how the two systems are hosted.)

There are several obvious ways to deal with this:

1. Don't share work-trees. That's probably the best method.
2. Don't allow one of the systems to update the index (by making it read-only there—this may be a bit tricky).
3. Use a separate index on one of the systems: the default index is $GIT_DIR/index where $GIT_DIR is from the environment or defaulted from git rev-parse --git-dir, but setting GIT_INDEX_FILE to a path name will override this.

The reason I suggest method 1 is that it's built in to Git, if your Git is at least version 2.5, using git worktree add. Note that each Git work-tree must be in its own branch, or use a detached HEAD; the detached HEAD method is probably fine for this purpose, just use git checkout --detach <branch> there to update.

Beall

I didn't know it was possible to change the index path. I now have set GIT_INDEX_FILE to .git/index-win on Windows, and this seems to work like a charm. – Cathodoluminescence

You should force the index to update, as stated at https://mcmap.net/q/361643/-how-to-recover-git-index-locally – Pardner

@denispyr: to really force a complete update you must remove and rebuild the index, otherwise Git may re-use stale index data. But this is a destructive operation so it's not something you should do casually. – Beall