All of lore.kernel.org
 help / color / mirror / Atom feed
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(-)

  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.com \
    --cc=git@vger.kernel.org \
    --cc=mhagger@alum.mit.edu \
    --cc=sahlberg@google.com \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.