From: Junio C Hamano <gitster@pobox•com>
To: Michael Haggerty <mhagger@alum•mit.edu>
Cc: git@vger•kernel.org, Ronnie Sahlberg <sahlberg@google•com>
Subject: Re: [PATCH 0/4] Make update_refs more atomic V2
Date: Thu, 10 Apr 2014 11:53:28 -0700 [thread overview]
Message-ID: <xmqq38hlxbh3.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1397154625-11884-1-git-send-email-sahlberg@google.com> (Ronnie Sahlberg's message of "Thu, 10 Apr 2014 11:30:21 -0700")
CC'ing Michael who has been active in this area as an area expert.
Ronnie, please make it a habit to run something like
$ git shortlog --no-merges --since=18.months <affected paths>...
to help you decide who your series may want to be reviewed by,
before sending them.
Thanks.
Ronnie Sahlberg <sahlberg@google•com> writes:
> refs.c:update_refs() intermingles doing updates and checks with actually
> applying changes to the refs in loops that abort on error.
> This is done one ref at a time and means that if an error is detected that
> will fail the operation after only some of the ref operations have been
> been updated on the disk.
>
> These patches change the update and delete functions to use a three
> call pattern of
>
> 1, lock
> 2, update, or flag for deletion
> 3, apply on disk
>
> In the final patch I change update_refs to perform these actions in three
> separate loops where the final loop to 'apply on disk' all the changes will
> only be performed if there were no error conditions detected during any of
> previous loops.
>
> This should make the changes of refs in update_refs slightly more atomic.
>
>
> This may overlap with other current patch series for making refs updates
> more atomic which may mean these patches become obsolete, but I would still
> like some review and feedback on these changes.
>
> Version 2:
> Updates and fixes based on Junio's feedback.
> * Fix the subject line for patches so they comply with the project standard.
> * Redo the update/delete loops so that we maintain the correct order of
> operations. Perform all updates first, then perform the deletes.
> * Add an additional patch that allows us to do the update/delete in the correct
> order from within a single loop by first sorting the refs so that deletes
> are after all non-deletes.
>
>
> Ronnie Sahlberg (4):
> refs.c: split writing and commiting a ref into two separate functions
> refs.c: split delete_ref_loose() into a separate flag-for-deletion and
> commit phase
> refs.c: change update_refs to run the commit loops once all work is
> finished
> refs.c: sort the refs by new_sha1 and merge the two update/delete
> loops into one
>
> branch.c | 10 ++++-
> builtin/commit.c | 5 +++
> builtin/fetch.c | 7 +++-
> builtin/receive-pack.c | 4 ++
> builtin/replace.c | 6 ++-
> builtin/tag.c | 6 ++-
> fast-import.c | 7 +++-
> refs.c | 102 +++++++++++++++++++++++++++++++++----------------
> refs.h | 6 +++
> sequencer.c | 4 ++
> walker.c | 4 ++
> 11 files changed, 123 insertions(+), 38 deletions(-)
next prev parent reply other threads:[~2014-04-10 18:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 18:30 [PATCH 0/4] Make update_refs more atomic V2 Ronnie Sahlberg
2014-04-10 18:30 ` [PATCH 1/4] refs.c: split writing and commiting a ref into two separate functions Ronnie Sahlberg
2014-04-10 18:30 ` [PATCH 2/4] refs.c: split delete_ref_loose() into a separate flag-for-deletion and commit phase Ronnie Sahlberg
2014-04-10 18:30 ` [PATCH 3/4] refs.c: change update_refs to run the commit loops once all work is finished Ronnie Sahlberg
2014-04-10 18:30 ` [PATCH 4/4] refs.c: sort the refs by new_sha1 and merge the two update/delete loops into one Ronnie Sahlberg
2014-04-10 19:01 ` Junio C Hamano
2014-04-10 19:40 ` Ronnie Sahlberg
2014-04-10 18:53 ` Junio C Hamano [this message]
2014-04-10 20:08 ` [PATCH 0/4] Make update_refs more atomic V2 Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq38hlxbh3.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=mhagger@alum$(echo .)mit.edu \
--cc=sahlberg@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox