On Fri, Jul 3, 2009 at 2:28 AM, Linus Torvalds<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > 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 Great! Thanks for the really detailed reply; appreciate it very much. I knew about core.PreloadIndex simply due to searching "man git-config" for NFS etc., but not the rest of it. > 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. Though I asked this following from a debate on IRC, it now looks as if this will solve another of my problems too. Let me explain. I'm evangelising git at work, and although most projects are happy, even eager to setup a proper server for git, and those that can't are happy to just use mine, there are a couple of projects that are almost exclusively Windows _and_ cannot add another machine _and_ have client confidentiality issues so they can't just use my server. My alternatives for them so far were (1) VirtualBox running Fedora or something within one of their beefier Windows servers or (2) the whole cygwin install, which is painful compared to msysgit. Sounds like we can just do it with traditional Windows fileshares, as long as we make sure no one does a "git gc" on the bare repo that is being shared. That's a very small price to pay! Thanks once again, and I'm copying Gitte in case he has anything to add, seeing I have sneakily changed the focus of the question now :-) [It wasn't pre-meditated, honest!] Sitaram -- 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