From: Patrick Steinhardt <ps@pks.im>
To: Elijah Newren <newren@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 6/6] fetch: make `--atomic` flag cover pruning of refs
Date: Thu, 17 Feb 2022 13:06:24 +0100 [thread overview]
Message-ID: <Yg46QLSB5VFnK/M5@ncase> (raw)
In-Reply-To: <CABPp-BE9_RVu28C-6QuY2qDYaEExeqCqph0e37DgiFtPZRHY2A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3391 bytes --]
On Wed, Feb 16, 2022 at 05:40:19PM -0800, Elijah Newren wrote:
> On Fri, Feb 11, 2022 at 12:25 AM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > When fetching with the `--prune` flag we will delete any local
> > references matching the fetch refspec which have disappeared on the
> > remote. This step is not currently covered by the `--atomic` flag: we
> > delete branches even though updating of local references has failed,
> > which means that the fetch is not an all-or-nothing operation.
> >
> > Fix this bug by passing in the global transaction into `prune_refs()`:
> > if one is given, then we'll only queue up deletions and not commit them
> > right away.
> >
> > This change also improves performance when pruning many branches in a
> > repository with a big packed-refs file: every references is pruned in
> > its own transaction, which means that we potentially have to rewrite
> > the packed-refs files for every single reference we're about to prune.
> >
> > The following benchmark demonstrates this: it performs a pruning fetch
> > from a repository with a single reference into a repository with 100k
> > references, which causes us to prune all but one reference. This is of
> > course a very artificial setup, but serves to demonstrate the impact of
> > only having to write the packed-refs file once:
> >
> > Benchmark 1: git fetch --prune --atomic +refs/*:refs/* (HEAD~)
> > Time (mean ± σ): 2.366 s ± 0.021 s [User: 0.858 s, System: 1.508 s]
> > Range (min … max): 2.328 s … 2.407 s 10 runs
> >
> > Benchmark 2: git fetch --prune --atomic +refs/*:refs/* (HEAD)
> > Time (mean ± σ): 1.369 s ± 0.017 s [User: 0.715 s, System: 0.641 s]
> > Range (min … max): 1.346 s … 1.400 s 10 runs
> >
> > Summary
> > 'git fetch --prune --atomic +refs/*:refs/* (HEAD)' ran
> > 1.73 ± 0.03 times faster than 'git fetch --prune --atomic +refs/*:refs/* (HEAD~)'
>
> Very nice!
>
> [...]
> > diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> > index 93a0db3c68..afa6bf9f7d 100755
> > --- a/t/t5510-fetch.sh
> > +++ b/t/t5510-fetch.sh
> > @@ -349,11 +349,9 @@ test_expect_success 'fetch --atomic --prune executes a single reference transact
> > cat >expected <<-EOF &&
> > prepared
> > $ZERO_OID $ZERO_OID refs/remotes/origin/scheduled-for-deletion
> > - committed
> > - $ZERO_OID $ZERO_OID refs/remotes/origin/scheduled-for-deletion
> > - prepared
> > $ZERO_OID $head_oid refs/remotes/origin/new-branch
> > committed
>
> Up to here this is just what I expected.
>
> > + $ZERO_OID $ZERO_OID refs/remotes/origin/scheduled-for-deletion
> > $ZERO_OID $head_oid refs/remotes/origin/new-branch
>
> But now scheduled-for-deletion and new-branch are both listed again
> even with your fixes? Is this some peculiarity of the reference
> transaction hook that it lists the refs again after the
> prepared...committed block? (It may well be; I'm not that familiar
> with this area of the code.)
Yes, the reference-transaction hook is executed for each of the
"prepared", "committed" and "aborted" phases and gets as input all the
refs that have been queued for that phase.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2022-02-17 12:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-11 7:46 [PATCH 0/6] fetch: improve atomicity of `--atomic` flag Patrick Steinhardt
2022-02-11 7:46 ` [PATCH 1/6] fetch: increase test coverage of fetches Patrick Steinhardt
2022-02-15 6:19 ` Christian Couder
2022-02-17 11:13 ` Patrick Steinhardt
2022-02-11 7:46 ` [PATCH 2/6] fetch: backfill tags before setting upstream Patrick Steinhardt
2022-02-15 6:43 ` Christian Couder
2022-02-11 7:46 ` [PATCH 3/6] fetch: control lifecycle of FETCH_HEAD in a single place Patrick Steinhardt
2022-02-15 7:32 ` Christian Couder
2022-02-17 11:18 ` Patrick Steinhardt
2022-02-11 7:46 ` [PATCH 4/6] fetch: report errors when backfilling tags fails Patrick Steinhardt
2022-02-15 7:52 ` Christian Couder
2022-02-17 11:27 ` Patrick Steinhardt
2022-02-17 12:47 ` Patrick Steinhardt
2022-02-16 23:35 ` Jonathan Tan
2022-02-17 1:31 ` Elijah Newren
2022-02-11 7:47 ` [PATCH 5/6] fetch: make `--atomic` flag cover backfilling of tags Patrick Steinhardt
2022-02-15 8:11 ` Christian Couder
2022-02-16 23:41 ` Jonathan Tan
2022-02-17 11:37 ` Patrick Steinhardt
2022-02-17 1:34 ` Elijah Newren
2022-02-17 11:58 ` Patrick Steinhardt
2022-02-11 7:47 ` [PATCH 6/6] fetch: make `--atomic` flag cover pruning of refs Patrick Steinhardt
2022-02-15 9:12 ` Christian Couder
2022-02-17 12:03 ` Patrick Steinhardt
2022-02-16 23:39 ` Jonathan Tan
2022-02-17 1:40 ` Elijah Newren
2022-02-17 12:06 ` Patrick Steinhardt [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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yg46QLSB5VFnK/M5@ncase \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=newren@gmail.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.