All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Christian Couder <christian.couder@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH 1/6] fetch: increase test coverage of fetches
Date: Thu, 17 Feb 2022 12:13:14 +0100	[thread overview]
Message-ID: <Yg4tyssgW9OAu6K/@ncase> (raw)
In-Reply-To: <CAP8UFD2HswmXhqYTAMxQ0iYFtsErMS=DB18iv52Ujs=cAW9ytw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5303 bytes --]

On Tue, Feb 15, 2022 at 07:19:19AM +0100, Christian Couder wrote:
> On Fri, Feb 11, 2022 at 8:38 PM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > The `--atomic` flag is missing test coverage for pruning of deleted
> > references and backfilling of tags, and of course both aren't covered
> > correctly by this flag.
> 
> It's not clear to me what "both aren't covered correctly by this flag"
> actually means here. If it means that pruning of deleted references
> and backfilling of tags don't work correctly when --atomic is used,
> then it could be stated more clearly. Otherwise this seems to just be
> repeating the first part of the sentence.

Yeah, the commit message was a bit lazy to be honest. I've reworded it
to hopefully make clearer what one is looking at.

> > Furthermore, we don't have tests demonstrating
> > error cases for backfilling tags.
> >
> > Add tests to cover those testing gaps.
> >
> > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> 
> > +test_expect_success 'atomic fetch with failing backfill' '
> > +       git init clone3 &&
> > +
> > +       # We want to test whether a failure when backfilling tags correctly
> > +       # aborts the complete transaction when `--atomic` is passed: we should
> > +       # neither create the branch nor should we create the tag when either
> > +       # one of both fails to update correctly.
> > +       #
> > +       # To trigger failure we simply abort when backfilling a tag.
> > +       write_script clone3/.git/hooks/reference-transaction <<-\EOF &&
> > +               #!/bin/sh
> > +
> > +               while read oldrev newrev reference
> > +               do
> > +                       if test "$reference" = refs/tags/tag1
> > +                       then
> > +                               exit 1
> > +                       fi
> > +               done
> > +       EOF
> > +
> > +       test_must_fail git -C clone3 fetch --atomic .. $B:refs/heads/something &&
> > +
> > +       # Creation of the tag has failed, so ideally refs/heads/something
> > +       # should not exist. The fact that it does is demonstrates that there is
> 
> s/The fact that it does is demonstrates/The fact that it does demonstrates/
> 
> > +       # missing coverage in the `--atomic` flag.
> 
> Maybe s/missing coverage/a bug/ would make things clearer.
> 
> > +       test $B = "$(git -C clone3 rev-parse --verify refs/heads/something)"
> > +'
> 
> As this patch series is about fixing buggy parts of the behavior with
> --atomic, I think it would make more sense to use test_expect_failure,
> instead of test_expect_success, in this test, and to check that we
> have the correct behavior, instead of checking that we have the buggy
> behavior.
> 
> Of course when later in this patch series the buggy behavior is fixed,
> then test_expect_failure should be replaced with test_expect_success.

The downside of using `test_expect_failure` is that one cannot easily
see what exactly is broken in the testcase. Yes, you can document it,
but when using `test_expect_success` the huge advantage is that you can
see exactly what behaviour is changing in subsequent commits by just having a look
at the diff of the test which adapts it from its initially-broken state
to the newly-fixed behaviour.

> > +test_expect_success 'atomic fetch with backfill should use single transaction' '
> > +       git init clone4 &&
> > +
> > +       # Fetching with the `--atomic` flag should update all references in a
> > +       # single transaction, including backfilled tags. We thus expect to see
> > +       # a single reference transaction for the created branch and tags.
> > +       cat >expected <<-EOF &&
> > +               prepared
> > +               $ZERO_OID $B refs/heads/something
> > +               $ZERO_OID $S refs/tags/tag2
> > +               committed
> > +               $ZERO_OID $B refs/heads/something
> > +               $ZERO_OID $S refs/tags/tag2
> > +               prepared
> > +               $ZERO_OID $T refs/tags/tag1
> > +               committed
> > +               $ZERO_OID $T refs/tags/tag1
> > +       EOF
> 
> The comment says that we expect to see a single reference transaction,
> but the expected file we create seems to show 2 transactions. So I
> think here too, we should use test_expect_failure, instead of
> test_expect_success, and check that we have the correct behavior
> instead of a buggy one.

Same comment as above. I've also amended the commit message to say why
we're introducing the tests like this.

> > +       write_script clone4/.git/hooks/reference-transaction <<-\EOF &&
> 
> Here there is no #!/bin/sh while other uses of write_script in your
> patch have it. If it's not necessary, it could be removed in the other
> uses.

Good point, I always forget that the shebang is added automatically by
this helper.

> > +               ( echo "$*" && cat ) >>actual
> > +       EOF
> > +
> > +       git -C clone4 fetch --atomic .. $B:refs/heads/something &&
> > +       test_cmp expected clone4/actual
> > +'
> 
> I took a quick look at the 2 other tests after this one, and I think
> test_expect_failure should be used there too, instead of
> test_expect_success.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-02-17 11:13 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 [this message]
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

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=Yg4tyssgW9OAu6K/@ncase \
    --to=ps@pks.im \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.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.
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.