Johan Herland <johan@xxxxxxxxxxx> writes: >> Agreed. We may notice the failure to correct the permissions in the >> new code, where the old code left existing directories incorrect >> permissions as they were. > > I'm trying to mentally construct a scenario where two writers with > different configuration contexts ... > This case is unfortunate, but no different than if steps 3 and 4 are > swapped, i.e. the case where fetch B fails because the repo is not yet > group-writable. Also, remember that as part of changing > core.sharedRepository like this (step 3), we also require the admin to > manually alter the permission bits of existing object dirs, to make > sure they are group-writable (call this step 3.5). All of this has to > happen _while_ fetch A is running. > > Trying to code around this (frankly insane) case in the > create_tmpfile()/adjust_shared_perm() code is IMHO silly. I agree. Note that "We may notice" above were not meant as "we would fail unnecessarily in some cases where we did not, which is a regression". Both the old and the new code will have problems when two different users race with each other while having umask that is unsuitable for working together. -- 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