From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, johannes.schindelin@gmx.de, peff@peff.net,
Derrick Stolee <dstolee@microsoft.com>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2 1/2] t5510-fetch.sh: demonstrate fetch.writeCommitGraph bug
Date: Wed, 23 Oct 2019 16:18:13 +0200 [thread overview]
Message-ID: <20191023141813.GA26017@szeder.dev> (raw)
In-Reply-To: <6ac0a05746df8ac3b1dd788f525b2620bc4d9a08.1571835695.git.gitgitgadget@gmail.com>
On Wed, Oct 23, 2019 at 01:01:34PM +0000, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee <dstolee@microsoft.com>
>
> While dogfooding, Johannes found a bug in the fetch.writeCommitGraph
> config behavior. His example initially happened during a clone with
> --recurse-submodules, we found that this happens with the first fetch
> after cloning a repository that contains a submodule:
>
> $ git clone <url> test
> $ cd test
> $ git -c fetch.writeCommitGraph=true fetch origin
> Computing commit graph generation numbers: 100% (12/12), done.
> BUG: commit-graph.c:886: missing parent <hash1> for commit <hash2>
> Aborted (core dumped)
>
> In the repo I had cloned, there were really 60 commits to scan, but
> only 12 were in the list to write when calling
> compute_generation_numbers(). A commit in the list expects to see a
> parent, but that parent is not in the list.
>
> A follow-up will fix the bug, but first we create a test that
> demonstrates the problem.
>
> I used "test_expect_failure" for the entire test instead of
> "test_must_fail" only on the command that I expect to fail. This is
> because the BUG() returns an exit code so test_must_fail complains.
I don't think this paragraph is necessary; using 'test_expect_failure'
is the way to demonstrate a known breakage.
'test_must_fail' should only be used when the failure is the desired
behavior of a git command. (I used the word "desired" here, because
you just used the word "expect" above in the sense that "I expect it
to fail, because I know it's buggy, and I want to demonstrate that
bug")
> Helped-by: Jeff King <peff@peff.net>
> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Helped-by: Szeder Gábor <szeder.dev@gmail.com>
> Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
> ---
> t/t5510-fetch.sh | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> index ecabbe1616..e8ae3af0b6 100755
> --- a/t/t5510-fetch.sh
> +++ b/t/t5510-fetch.sh
> @@ -583,6 +583,23 @@ test_expect_success 'fetch.writeCommitGraph' '
> )
> '
>
> +test_expect_failure 'fetch.writeCommitGraph with submodules' '
> + pwd="$(pwd)" &&
> + git clone dups super &&
> + (
> + cd super &&
> + git submodule add "file://$pwd/three" &&
Nits: couldn't the URL simply be file://$TRASH_DIRECTORY/three ?
> + git commit -m "add submodule"
> + ) &&
> + git clone "super" writeError &&
There is a write error now, because we have a bug, but after the next
patch the bug will be fixed and we won't have a write error anymore.
> + (
> + cd writeError &&
> + test_path_is_missing .git/objects/info/commit-graphs/commit-graph-chain &&
> + git -c fetch.writeCommitGraph=true fetch origin &&
> + test_path_is_file .git/objects/info/commit-graphs/commit-graph-chain
> + )
> +'
> +
> # configured prune tests
>
> set_config_tristate () {
> --
> gitgitgadget
>
next prev parent reply other threads:[~2019-10-23 14:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-22 17:28 [PATCH 0/1] [v2.24.0-rc0 BUG] fetch.writeCommitGraph fails on first fetch Derrick Stolee via GitGitGadget
2019-10-22 17:28 ` [PATCH 1/1] commit-graph: fix writing first commit-graph during fetch Derrick Stolee via GitGitGadget
2019-10-22 20:33 ` Jeff King
2019-10-22 21:45 ` Jeff King
2019-10-22 23:35 ` SZEDER Gábor
2019-10-23 0:35 ` Derrick Stolee
2019-10-23 0:48 ` Jeff King
2019-10-23 1:22 ` Jeff King
2019-10-23 13:01 ` [PATCH v2 0/2] [v2.24.0-rc0 BUG] fetch.writeCommitGraph fails on first fetch Derrick Stolee via GitGitGadget
2019-10-23 13:01 ` [PATCH v2 1/2] t5510-fetch.sh: demonstrate fetch.writeCommitGraph bug Derrick Stolee via GitGitGadget
2019-10-23 14:18 ` SZEDER Gábor [this message]
2019-10-23 20:46 ` Derrick Stolee
2019-10-24 12:18 ` SZEDER Gábor
2019-10-23 13:01 ` [PATCH v2 2/2] commit-graph: fix writing first commit-graph during fetch Derrick Stolee via GitGitGadget
2019-10-23 15:04 ` SZEDER Gábor
2019-10-24 10:39 ` Derrick Stolee
2019-10-30 14:31 ` SZEDER Gábor
2019-10-24 12:18 ` [PATCH v3 0/2] [v2.24.0-rc0 BUG] fetch.writeCommitGraph fails on first fetch Derrick Stolee via GitGitGadget
2019-10-24 12:18 ` [PATCH v3 1/2] t5510-fetch.sh: demonstrate fetch.writeCommitGraph bug Derrick Stolee via GitGitGadget
2019-10-24 12:18 ` [PATCH v3 2/2] commit-graph: fix writing first commit-graph during fetch Derrick Stolee via GitGitGadget
2019-10-24 13:40 ` [PATCH v4 0/2] [v2.24.0-rc0 BUG] fetch.writeCommitGraph fails on first fetch Derrick Stolee via GitGitGadget
2019-10-24 13:40 ` [PATCH v4 1/2] t5510-fetch.sh: demonstrate fetch.writeCommitGraph bug Derrick Stolee via GitGitGadget
2019-10-24 13:40 ` [PATCH v4 2/2] commit-graph: fix writing first commit-graph during fetch Derrick Stolee via GitGitGadget
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=20191023141813.GA26017@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=peff@peff.net \
/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.