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 <tbullock@comlore.com>