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 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 NNTP newsgroup(s).