From: Junio C Hamano <gitster@pobox.com>
To: "Abhradeep Chakraborty via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Derrick Stolee <derrickstolee@github.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
Subject: Re: [PATCH] partial-clone: add a partial-clone test case
Date: Sun, 13 Mar 2022 19:41:21 +0000 [thread overview]
Message-ID: <xmqq4k41vdwe.fsf@gitster.g> (raw)
In-Reply-To: <pull.1175.git.1647193162570.gitgitgadget@gmail.com> (Abhradeep Chakraborty via GitGitGadget's message of "Sun, 13 Mar 2022 17:39:22 +0000")
"Abhradeep Chakraborty via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> From: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
>
> In a blobless-cloned repo, `git log --follow -- <path>` (`<path>` have
> an exact OID rename) doesn't download blob of the file from where the
> new file is renamed.
Is this "doesn't" (documenting current behaviour, without saying if
it is wrong or is desired) or "shouldn't" (documenting the desired
behaviour, which the current implementation may or may not satisfy)?
> +test_expect_success 'git log --follow does not download blobs if an exact OID rename found (blobless clone)' '
That's mouthful.
> + rm -rf repo partial.git &&
> + test_create_repo repo &&
> + content="some dummy content" &&
> + test_commit -C repo create-a-file file.txt "$content" &&
> + git -C repo mv file.txt new-file.txt &&
> + git -C repo commit -m rename-the-file &&
> + test_config -C repo uploadpack.allowfilter 1 &&
> + test_config -C repo uploadpack.allowanysha1inwant 1 &&
> +
> + git clone --filter=blob:none "file://$(pwd)/repo" partial.git &&
> + GIT_TRACE2_EVENT="$(pwd)/trace.txt" \
> + git -C partial.git log --follow -- new-file.txt > "$(pwd)/trace.txt" &&
Lose SP after '>'.
git -C partial.git log --follow -- new-file.txt >"$(pwd)/trace.txt" &&
> + ! test_subcommand_inexact fetch <trace.txt
Looking at the implementation of the helper, it seems to be prepared
to handle negation itself. Shouldn't this be
test_subcommand_inexact ! fetch <trace.txt
instead?
> +'
> +
> test_expect_success 'lazy-fetch when accessing object not in the_repository' '
> rm -rf full partial.git &&
> test_create_repo full &&
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index 0f439c99d61..07a2b60c103 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -1811,7 +1811,7 @@ test_subcommand_inexact () {
> shift
> fi
>
> - local expr=$(printf '"%s".*' "$@")
> + local expr=$(printf '.*"%s".*' "$@")
The original wanted to make sure that the arguments to the helper
are initial items of a comma separated list, and an existing caller,
for example, i.e.
test_subcommand_inexact git pack-objects --honor-pack-keep <trace
is relying on the behaviour to make sure 'git', 'pack-objects', ...
appear at the beginning of "[...]" enclosed list. This change
breaks its ability to notice that an insertion of unrelated token
before 'git' as an error.
In other words, it looks like an uncalled-for selfish change.
Why can't you specify what should NOT come before "fetch" in your
use of this helper?
> expr="${expr%,}"
The preimage already has this problem, but the stripping of trailing
comma here is a result of mistaken copy-and-paste from the exact
variant, I think. test_subcommand uses
local expr=$(printf '"%s",' "$@")
to concatenate "$@" into a single comma-separated string, so it
perfectly makes sense to drop the last one here, but with or without
your change here, neither is adding a comma that need to be
stripped.
It is not _your_ theme, but I think this helper is poorly designed,
especially compared to the original "exact" variant.
test_subcommand_inexact () {
local negate=
if test "$1" = "!"
then
negate=t
shift
fi
local expr=$(printf '"%s".*' "$@")
expr="${expr%,}"
if test -n "$negate"
then
! grep "\"event\":\"child_start\".*\[$expr\]"
else
grep "\"event\":\"child_start\".*\[$expr\]"
fi
}
I've already touched that "${expr%,}" there is a totally useful
statement that will always be a no-op.
When "test_subcommand_inexact git pack-objects" is run, the printf
assigns to $expr:
expr='"git".*"pack-objects".*'
and the actual grep command invoked becomes
grep '"event":"child_start".*\["git".*"pack-objects".*\]'
I am not sure if that is what we really want.
I wonder if it was more like this that the original wanted to grep for:
grep '"event":"child_start".*\["git","pack-objects",.*\]'
in which case the two lines there should be more like
local expr=$(printf '"%s",' "$@")
expr="${expr%,}.*"
I would think. This comes from Derrick's e4d0c11c (repack: respect
kept objects with '--write-midx -b', 2021-12-20).
next prev parent reply other threads:[~2022-03-13 19:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-13 17:39 [PATCH] partial-clone: add a partial-clone test case Abhradeep Chakraborty via GitGitGadget
2022-03-13 19:41 ` Junio C Hamano [this message]
2022-03-14 15:46 ` Abhradeep Chakraborty
2022-03-14 16:25 ` Derrick Stolee
2022-03-14 21:42 ` Junio C Hamano
2022-03-15 8:20 ` Abhradeep Chakraborty
2022-03-14 21:35 ` Junio C Hamano
2022-03-14 16:24 ` Derrick Stolee
2022-03-14 22:21 ` Junio C Hamano
2022-03-15 11:30 ` Abhradeep Chakraborty
2022-03-15 12:57 ` Derrick Stolee
2022-03-15 15:15 ` Abhradeep Chakraborty
2022-03-15 16:13 ` Junio C Hamano
2022-03-16 8:06 ` Abhradeep Chakraborty
2022-03-16 9:46 ` [PATCH v2] " Abhradeep Chakraborty via GitGitGadget
2022-03-21 15:26 ` Derrick Stolee
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=xmqq4k41vdwe.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=chakrabortyabhradeep79@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@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).