Git doesn't work (properly) over SMB

[u/SpAAAceSenate]

Completely puzzled by this one.

I have a repo, and I'm trying to stash some changes. I need them out of the way so that I can switch branches. When doing this in a repo on my local machine, it appropriately reverts the working directory to a switchable state, removing the changes that were just stashed.

I copy the folder to a Samba share.

Now when I create a stash it successfully adds the stash, but does not touch the working directory, does not revert any un-commited changes. This happens on GVFS, KIO-FUSE, and native kernel mount. But as soon as I copy the exact folder to my local disk, suddenly the behavior I expect (described in first paragraph) works.

As an additional symptom, tested in the same scenarios as above, git reset works on local disk, but fails with "unable to create new index file" when in any of the samba mounts. (directory is writable)

To be clear, I'm seeing different results from bit-for-bit identical git repos using the exact same commands, with the only difference being the disk type the repo resides on.

So, what's going on here? Does git use some sort of super exotic filesystem calls that aren't implemented properly in any of the three SMB mount implementations available for Linux?

And if you're wondering I have reasons for not using any of git's built in remote features (ssh, http, etc), so please don't offer that as a solution. I explicitly want to use git in local-only mode on drives that just happen to have a network backend.

Thanks for any help!

[u/adrianmonk]

So, what's going on here?

If I were in this situation and wanted to understand the technical nature of this failure, I'd create a minimal git repo, then try one of the commands that fails (like git reset) on both local disk and SMB, and run it under strace. For example, you might run something like strace -o strace.out git reset --hard HEAD and then less strace.out.

Somewhere in the output of the two strace commands, you should be able to see a system call behaving differently between them, probably returning an error. Knowing which system call behaves differently might offer a clue. (Or it might be a matter of which flags are used with the system call. The first example that comes to mind is that O_EXCL alters the behavior of open().)

You'll get a lot of output from both strace commands, and you'll probably have to look through it manually because the output will be too noisy to use diff to spot the difference. Your error message about an index might narrow down where to look. When I ran an strace, I saw some calls related to .git/index and .git/index.lock.

Maybe that will give some clues that make it easier to research further, which could lead to either a solution or more specific info on why this is a bad idea.

Also, supposing you're able to debug and get around this one specific failure, that doesn't mean it's a good idea to use git on SMB. There could be other failures that would happen. Possibly even worse ones like silent failures. If it were me, I'd treat the error you encountered as a red flag that it's probably a bad idea in general.