From: Ted Bullock Subject: Re: Workflow question, maybe bug or unclear usage. To: Christian Weisgerber , gameoftrees@openbsd.org Date: Fri, 28 Jan 2022 12:13:43 -0700 On 2022-01-27 3:47 p.m., Stefan Sperling wrote: > The fix has been committed. > > I would advise against modifying work trees with clients that access the > work tree over NFS. This might trigger problems if multiple clients > operate on the work tree in parallel for some reason. Got relies on > flock(2) to ensure exclusive access, and relies on "atomic" rename > behaviour while updating files with new content, which is not guaranteed > over NFS. > > Sharing a work tree to other machines over read-only NFS is perfectly > safe. 'got status' will work even if run from other machines because > it does not lock the work tree. Though this means that it might show > inconsistent state or even error out on occasion if it happens to run > in parallel to other commands. > Most got commands will likely fail on a read-only work tree. > > Ideally, each machine should have its own local repo clone and source tree. > But I understand that this is not always feasible. Thanks, this is the kind of workflow answer I was looking for. Out of curiosity has anyone looked to see what mechanisms git is using for these operations? For the /usr/src tree git seems to be able run a status command over nfs in under a minute on the old sparc64 system I've been testing on whereas got takes around 11 to complete its own status command on this machine. $ time got status 10m44.59s real 0m23.81s user 2m11.92s system -- Ted Bullock