On Thu, 2 Jul 2009, Sitaram Chamarty wrote: > > A couple of us were beating each other senseless on this > issue over on #git, so I thought I'd ask: is it OK to do > this? Or would there potential be race conditions due to > the lack of proper locking? It should all work fine. We've had a few NFS issues due to oddities with renaming across directories, but modern git avoids the cross-directory renames, and that whole issue only hit some very specific cases anyway. And git doesn't have "proper locking", because it doesn't need it for database ops: git objects are stable. For refs, git should be using the proper NFS-safe "create and atomic rename" ops. You do need to be a bit careful if you do maintenance operations concurrently (I would suggest avoiding doing concurrent "git gc --prune", for example), but any normal git workflow should be fine. There is one big thing to look out for: performance. You may want to add [core] PreloadIndex = true in your .git/config file, especially if you have a high-latency NFS server (but if you have a fast network and a high-end NFS server, you might be better off without it, so do your own testing). Btw, I think we fixed the problem we had with CIFS. That one was a cifs filesystem problem on Linux, but it should be fixed in 2.6.30+ (commit 0f4d634c: "cifs: flush data on any setattr"). If you have an older kernel (or are just uncertain), you can also work around it with [core] fsyncobjectfiles = true which may be a good thing in general (regardless of any cifs issues), but in most cases the performance loss isn't worth it if your filesystem is stable and sane. Linus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html