Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> writes: > A script I'm writing performs a succession of porcelain commands to > create a commit in a bare git repository: Meaning 'plumbing' commands? > > git hash-object > git mktree These take input and create a new object or if the data fed to them were somehow identical to an existing object, becomes a no-op. We take the data, hash to compute its name while writing it out as a loose object to a temporary file. After finishing this compute/write we can check if we already have the object and if so we can just clean up and leave. There is no race in this case. If there is no existing object, we rename the temporary file to the filename derived from the object name. If somebody else were creating exactly the same object at the same time, the renaming to the final name will fail for all but one of them, but in the end everybody gets the object they wanted to see in the repository unless you found a hash collision. These other "failing" folks would probably need to "redo" the operation, but when they do so, their compute/writes would safely become no-op. > git commit-tree This may write more than one objects; compute/write for each object competes with compute/write by other processes independently, but the overall story is the same. > git update-ref You can use the "old value MUST BE this" variant to avoid a race with another process that tries to update the same ref to a different value, but if the other process updates the same ref to a different value _after_ you are done, their update will overwrite what you did, so they also need to be using the same "old value MUST BE this" variant.
