Re: Do porcelain command require lock management?

Konstantin Ryabitsev [off-list ref] 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.