From: Taylor Blau <me@ttaylorr.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Jonathan Tan <jonathantanmy@google.com>, git@vger.kernel.org
Subject: Re: [PATCH] ls-files: support --recurse-submodules --stage
Date: Fri, 18 Feb 2022 22:50:18 -0500 [thread overview]
Message-ID: <YhBo+hg8yxIOGKNS@nand.local> (raw)
In-Reply-To: <220219.868ru7fsad.gmgdl@evledraar.gmail.com>
On Sat, Feb 19, 2022 at 04:11:30AM +0100, Ævar Arnfjörð Bjarmason wrote:
> But why do we need to test the OID abbreviation at all, isn't that a bit
> too much paranoia? Isn't it sufficient just do:
>
> opts="--stage --abbrev=4" &&
> git -C submodule ls-files $opts >expect &&
> git ls-files --recurse-submodules $opts --stage >raw &&
> grep submodule raw >actual &&
> test_cmp expect actual
Yeah; I like this direction. I try to err on the side of reconstructing
the whole output and then calling test_cmp on it. I usually go that way
because it's nice for somebody reading the test script to see what the
output is supposed to look like.
But because you have to have a bunch of $(git rev-parse --short=4 ...)
in subshells everywhere in order to produce the right output, I don't
think the result resembles the actual output in this case.
I'd probably go a bit further than what you propose, maybe replacing
that grep with:
grep "0.submodule" actual
to make sure that we got the correct stage number, too. But I agree with
you on the general direction.
Thanks,
Taylor
next prev parent reply other threads:[~2022-02-19 3:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-18 22:32 [PATCH] ls-files: support --recurse-submodules --stage Jonathan Tan
2022-02-19 0:33 ` Junio C Hamano
2022-02-19 3:11 ` Ævar Arnfjörð Bjarmason
2022-02-19 3:50 ` Taylor Blau [this message]
2022-02-21 18:19 ` Junio C Hamano
2022-02-21 18:51 ` Ævar Arnfjörð Bjarmason
2022-02-24 0:11 ` Jonathan Tan
2022-02-21 1:48 ` Junio C Hamano
2022-02-21 2:45 ` Taylor Blau
2022-02-24 0:23 ` [PATCH v2] " Jonathan Tan
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=YhBo+hg8yxIOGKNS@nand.local \
--to=me@ttaylorr.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=jonathantanmy@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 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.