All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.