From: Junio C Hamano <gitster@pobox.com>
To: Josip Sokcevic <sokcevic@google.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2] diff-lib: honor override_submodule_config flag bit
Date: Wed, 14 Jun 2023 09:14:04 -0700 [thread overview]
Message-ID: <xmqqa5x2xbqr.fsf@gitster.g> (raw)
In-Reply-To: <20230614153142.3138028-1-sokcevic@google.com> (Josip Sokcevic's message of "Wed, 14 Jun 2023 08:31:42 -0700")
Josip Sokcevic <sokcevic@google.com> writes:
> +add_submodule_commits_and_validate () {
> + HASH=$(git rev-parse HEAD) &&
> + git update-index --add --cacheinfo 160000,$HASH,sub &&
> + git commit -m "create submodule" &&
> + git ls-tree HEAD >output &&
> + test_when_finished "rm -f output" &&
> + grep "$HASH" output
If ls-tree exits with non-zero status, test_when_finished will not
be seen, and will not arrange output to be removed. If we are going
to use test_when_finished to remove the file, we should do so before
we do anything that potentially creates the file.
The test with "grep" is overly loose, as I suspect that you won't be
happy to see the $HASH (i.e. the commit object name) just anywhere
in the output, but exactly where you placed it, i.e. at path "sub".
So it may make more sense to do the test like so:
...
git commit -m "create" &&
echo "160000 commit $HASH sub" >expect &&
git ls-tree HEAD -- sub >actual &&
test_cmp expect actual
If we were to add
test_when_finished "rm -f expect actual" &&
we would do so immediately after "git commit" step, but I personally
do not think it is worth doing in this case. These two files are
what many if not most of our test pieces use and having them as
untracked files is a norm. Unless we have a need to have strict
control of what untracked files are in the working tree in later
tests, it is OK to leave these files around.
Other than that, looking much better.
Thanks.
> +}
> +
> +test_expect_success 'commit with staged submodule change' '
> + add_submodule_commits_and_validate
> +'
> +
> +test_expect_success 'commit with staged submodule change with ignoreSubmodules dirty' '
> + test_config diff.ignoreSubmodules dirty &&
> + add_submodule_commits_and_validate
> +'
> +
> +test_expect_success 'commit with staged submodule change with ignoreSubmodules all' '
> + test_config diff.ignoreSubmodules all &&
> + add_submodule_commits_and_validate
> +'
> +
> test_done
prev parent reply other threads:[~2023-06-14 16:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-14 15:31 [PATCH v2] diff-lib: honor override_submodule_config flag bit Josip Sokcevic
2023-06-14 16:14 ` Junio C Hamano [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=xmqqa5x2xbqr.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=sokcevic@google.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).