git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: git@vger.kernel.org
Subject: Re: Do porcelain command require lock management?
Date: Mon, 26 Oct 2020 10:56:48 -0700	[thread overview]
Message-ID: <xmqqy2jseuqn.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20201024144637.cvwa22f2y4tvfn4z@chatter.i7.local> (Konstantin Ryabitsev's message of "Sat, 24 Oct 2020 10:46:37 -0400")

Konstantin Ryabitsev <konstantin@linuxfoundation.org> 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.

      parent reply	other threads:[~2020-10-26 17:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-24 14:46 Do porcelain command require lock management? Konstantin Ryabitsev
2020-10-25 23:02 ` brian m. carlson
2020-10-26 16:36   ` Konstantin Ryabitsev
2020-10-26 17:56 ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqy2jseuqn.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=konstantin@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).