All of lore.kernel.org
 help / color / mirror / Atom feed
From: ZheNing Hu <adlternative@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: ZheNing Hu via GitGitGadget <gitgitgadget@gmail.com>,
	Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Christian Couder <christian.couder@gmail.com>
Subject: Re: [PATCH 1/2] ls-files: introduce "--format" option
Date: Sat, 18 Jun 2022 18:50:36 +0800	[thread overview]
Message-ID: <CAOLTT8SfRz62jVrdtjsGN=-iBAQzA3w_oJgT++xtx_kbdCmdqQ@mail.gmail.com> (raw)
In-Reply-To: <220615.86a6ady983.gmgdl@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> 于2022年6月16日周四 04:15写道:
>
>
> > +static void write_name_to_buf(struct strbuf *sb, const char *name)
> > +{
> > +     name = relative_path(name, prefix_len ? prefix : NULL, sb);
> FWIW I'd find this a bit less "huh?" if we declared another variable
> here, so just:
>
>         const char *rel = relative_path(name, ...).
>

Yeah, It's just a wrong code copy.

> > +     o1
> > +     EOF
> > +     git ls-files --format="%(path)" -m >actual &&
> > +     test_cmp expect actual
> > +'
> > +
> > +test_expect_success 'git ls-files --format with -d' '
> > +     rm o1 &&
>
> Don't "rm o1" here, rather have the test that creates it do:
>
>     test_when_finished "rm o1" &&
>     [the command that creates o1]
>

I thought about how to test 'git ls-files -d', so maybe I need
something like:

test_expect_success 'git ls-files --format with -d' '
     echo o3 >o3 &&
     git add o3 &&
     rm o3 &&
     cat >expect <<-\EOF &&
     o3
     EOF
     git ls-files --format="%(path)" -d >actual &&
     test_cmp expect actual
'

> > +     test_when_finished "git restore o1" &&
> > +     cat >expect <<-EOF &&
> > +     o1
> > +     EOF
> > +     git ls-files --format="%(path)" -d >actual &&
> > +     test_cmp expect actual
> > +'
> > +
>
> These tests...:
>
> > +test_expect_success 'git ls-files --format with -s must fail' '
> > +     test_must_fail git ls-files --format="%(objectname)" -s
> > +'
> > +
> > +test_expect_success 'git ls-files --format with -o must fail' '
> > +     test_must_fail git ls-files --format="%(objectname)" -o
> > +'
> > +
> > +test_expect_success 'git ls-files --format with -k must fail' '
> > +     test_must_fail git ls-files --format="%(objectname)" -k
> > +'
> > +
> > +test_expect_success 'git ls-files --format with --resolve-undo must fail' '
> > +     test_must_fail git ls-files --format="%(objectname)" --resolve-undo
> > +'
> > +
> > +test_expect_success 'git ls-files --format with --deduplicate must fail' '
> > +     test_must_fail git ls-files --format="%(objectname)" --deduplicate
> > +'
> > +
> > +test_expect_success 'git ls-files --format with --debug must fail' '
> > +     test_must_fail git ls-files --format="%(objectname)" --debug
> > +'
>
> ...would be better done with a for-loop, so:
>
>         for flag in -s -o -k --resolve-undo [...]
>         do
>                 test_expect_success "git ls-files --format is incompatible with $flag" '
>                         test_must_fail git ls-files --format="%(objectname)" $flag
>                 '
>         done
>

Yeah, using this loop will be clear.

> Note the '' on the second argument, that's intentional, as we eval it
> you don't need "".
>
> > +test_done
>

Thanks for all these code style suggestions!

ZheNing Hu

  reply	other threads:[~2022-06-18 10:50 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-15 13:45 [PATCH 0/2] ls-files: introduce "--format" and "--object-only" options ZheNing Hu via GitGitGadget
2022-06-15 13:45 ` [PATCH 1/2] ls-files: introduce "--format" option ZheNing Hu via GitGitGadget
2022-06-15 20:07   ` Ævar Arnfjörð Bjarmason
2022-06-18 10:50     ` ZheNing Hu [this message]
2022-06-15 13:45 ` [PATCH 2/2] ls-files: introduce "--object-only" option ZheNing Hu via GitGitGadget
2022-06-15 20:15   ` Ævar Arnfjörð Bjarmason
2022-06-18 10:59     ` ZheNing Hu
2022-06-19  9:13 ` [PATCH v2] ls-files: introduce "--format" option ZheNing Hu via GitGitGadget
2022-06-19 13:50   ` Phillip Wood
2022-06-20 13:32     ` ZheNing Hu
2022-06-21  2:05   ` [PATCH v3] " ZheNing Hu via GitGitGadget
2022-06-23 14:06     ` Phillip Wood
2022-06-23 15:57       ` Junio C Hamano
2022-06-24 10:16         ` Phillip Wood
2022-06-26 13:05           ` ZheNing Hu
2022-06-24 13:20         ` Ævar Arnfjörð Bjarmason
2022-06-24 15:28           ` Junio C Hamano
2022-06-26 13:01       ` ZheNing Hu
2022-06-24 13:25     ` Ævar Arnfjörð Bjarmason
2022-06-24 15:33       ` Junio C Hamano
2022-06-26 13:35         ` ZheNing Hu
2022-06-27  8:22           ` Junio C Hamano
2022-06-27 11:06             ` ZheNing Hu
2022-06-27 15:41               ` Junio C Hamano
2022-07-01 13:30                 ` ZheNing Hu
2022-06-26 13:34       ` ZheNing Hu
2022-06-26 15:29     ` [PATCH v4] " ZheNing Hu via GitGitGadget
2022-06-27  8:32       ` Junio C Hamano
2022-06-27 11:18         ` ZheNing Hu
2022-06-27 18:34       ` Ævar Arnfjörð Bjarmason
2022-07-01 12:42         ` ZheNing Hu
2022-06-28 15:19       ` Phillip Wood
2022-07-01 12:47         ` ZheNing Hu
2022-07-05  6:32       ` [PATCH v5] " ZheNing Hu via GitGitGadget
2022-07-05  8:39         ` Ævar Arnfjörð Bjarmason
2022-07-11 15:14           ` ZheNing Hu
2022-07-05 19:28         ` Torsten Bögershausen
2022-07-11 15:27           ` ZheNing Hu
2022-07-11 16:53         ` [PATCH v6] " ZheNing Hu via GitGitGadget
2022-07-11 22:11           ` Junio C Hamano
2022-07-12 13:53             ` ZheNing Hu
2022-07-12 14:34               ` Junio C Hamano
2022-07-13  6:07           ` [PATCH v7] " ZheNing Hu via GitGitGadget
2022-07-18  8:09             ` Ævar Arnfjörð Bjarmason
2022-07-19 16:19               ` ZheNing Hu
2022-07-19 16:47                 ` Junio C Hamano
2022-07-19 17:21                   ` ZheNing Hu
2022-07-20 16:36             ` [PATCH v8] " ZheNing Hu via GitGitGadget
2022-07-20 17:37               ` Junio C Hamano
2022-07-21 15:54                 ` Ævar Arnfjörð Bjarmason
2022-07-21 17:22                   ` Eric Sunshine
2022-07-21 17:23                   ` Junio C Hamano
2022-07-22  6:44                 ` ZheNing Hu
2022-07-23 18:40                   ` Junio C Hamano
2022-07-23 18:46                     ` Junio C Hamano
2022-07-24 11:08                     ` ZheNing Hu
2022-07-25  1:03                       ` Junio C Hamano
2022-07-25 11:00                         ` ZheNing Hu
2022-07-23  6:44               ` [PATCH v9] " ZheNing Hu via GitGitGadget
2022-09-08  2:01                 ` Jiang Xin
2022-09-11 11:01                   ` ZheNing Hu

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='CAOLTT8SfRz62jVrdtjsGN=-iBAQzA3w_oJgT++xtx_kbdCmdqQ@mail.gmail.com' \
    --to=adlternative@gmail.com \
    --cc=avarab@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.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.