git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hariom verma <hariom18599@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Hariom Verma via GitGitGadget" <gitgitgadget@gmail.com>,
	git <git@vger.kernel.org>,
	"Christian Couder" <christian.couder@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v3 3/3] ref-filter: use pretty.c logic for trailers
Date: Sun, 7 Feb 2021 17:36:45 +0530	[thread overview]
Message-ID: <CA+CkUQ9-OCiEkMDRTpyF3rp-g1mSSzn4s9MgqJZ2BJY=XJCoEw@mail.gmail.com> (raw)
In-Reply-To: <xmqqpn1c8m7u.fsf@gitster.c.googlers.com>

Hi,

On Sun, Feb 7, 2021 at 11:15 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Hariom Verma via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > +test_trailer_option() {
> > +     title="$1"
> > +     option="$2"
> > +     expect="$3"
> > +     test_expect_success "$title" '
> > +             printf "$expect\n" >expect &&
> > +             git for-each-ref --format="%($option)" refs/heads/main >actual &&
> > +             test_cmp expect actual &&
> > +             git for-each-ref --format="%(contents:$option)" refs/heads/main >actual &&
> > +             test_cmp expect actual
> > +     '
> > +}
> > +
> > +test_trailer_option '%(trailers:key=foo) shows that trailer' \
> > +     'trailers:key=Signed-off-by' 'Signed-off-by: A U Thor <author@example.com>\n'
>
> This is *not* an issue about the test script and its helper
> function, but I just noticed that --format="%(trailers:key=<key>)"
> is expected to write the matching trailers *AND* an empty line, and
> I wonder if that is a sensible thing to expect.
>
> The "--pretty" side does not give such an extra blank line after the
> output, though.
>
>  $ git show -s --pretty=format:"%(trailers:key=Signed-off-by:)" \
>    js/range-diff-wo-dotdot
>  Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>  Signed-off-by: Junio C Hamano <gitster@pobox.com>
>  $ git show -s --pretty=format:"%(trailers:key=None:)" \
>    js/range-diff-wo-dotdot
>  $ exit
>
> Unlike the above, when there is no matching trailer lines, the
> "for-each-ref" in this series shows zero lines, and when there is
> one matching trailer line, it gives that single line plus an empty
> line, two lines in total.  The inconsistency is a bit disturbing.
>
> Is the extra blank line given on purpose?  I don't see why we would
> want it.  Or is it a bug we did not catch during the previous two
> rounds of reviews?

I don't think that "extra blank line" is due to this patch series.
Wait. Let me see.

Since "for-each-ref"'s original code does not support
"trailers:key=<KEY>", Let's check original code for "trailers:only":
```
  $ git for-each-ref refs/heads/master --format="%(trailers:only)"
  Signed-off-by: Junio C Hamano <gitster@pobox.com>

  $ exit
```
I see. The original code also gives an extra blank line.

Now, let's check for this patch series:
```
  $ ./bin-wrappers/git for-each-ref refs/heads/master
--format="%(trailers:key=Signed-off-by)"
  Signed-off-by: Junio C Hamano <gitster@pobox.com>

  $ ./bin-wrappers/git for-each-ref refs/heads/master
--format="%(trailers:key=None)"

  $ exit
```
when there is no matching trailer lines, the "for-each-ref" in this
series shows one empty line, and when there is one matching trailer
line, it gives that single line plus an empty line, two lines in
total. Seems consistent to me.

So this isn't about the patch series. Question still remains the same.
Why extra blank line?
Let's dig a bit.
Ah. I guess I found the reason. It's due to `putchar('\n');` in
`show_ref_array_item() [1]`. It puts a new line after each ref item.

Do you want me to include a patch to get rid of this "extra blank
line" for trailers in "for-each-ref"?

Thanks,
Hariom.

[1]: https://github.com/git/git/blob/fb7fa4a1fd273f22efcafdd13c7f897814fd1eb9/ref-filter.c#L2435

  reply	other threads:[~2021-02-07 12:08 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-05 19:48 [PATCH 0/2] Unify trailers formatting logic for pretty.c and ref-filter.c Hariom Verma via GitGitGadget
2020-09-05 19:48 ` [PATCH 1/2] pretty.c: refactor trailer logic to `format_set_trailers_options()` Hariom Verma via GitGitGadget
2020-09-05 21:59   ` René Scharfe
2020-09-05 19:48 ` [PATCH 2/2] ref-filter: using pretty.c logic for trailers Hariom Verma via GitGitGadget
2021-01-29 21:09 ` [PATCH v2 0/3] Unify trailers formatting logic for pretty.c and ref-filter.c Hariom Verma via GitGitGadget
2021-01-29 21:09   ` [PATCH v2 1/3] pretty.c: refactor trailer logic to `format_set_trailers_options()` Hariom Verma via GitGitGadget
2021-01-29 23:49     ` Junio C Hamano
2021-01-29 21:09   ` [PATCH v2 2/3] pretty.c: capture invalid trailer argument Hariom Verma via GitGitGadget
2021-01-29 22:28     ` Christian Couder
2021-01-30 19:16       ` Hariom verma
2021-01-30  0:01     ` Junio C Hamano
2021-01-30 19:00       ` Hariom verma
2021-01-30  0:07     ` Junio C Hamano
2021-01-30 19:06       ` Hariom verma
2021-01-29 21:09   ` [PATCH v2 3/3] ref-filter: use pretty.c logic for trailers Hariom Verma via GitGitGadget
2021-01-30 20:45     ` Ævar Arnfjörð Bjarmason
2021-02-04 18:46       ` Hariom verma
2021-02-04 20:53         ` Ævar Arnfjörð Bjarmason
2021-01-30  1:17   ` [PATCH v2 0/3] Unify trailers formatting logic for pretty.c and ref-filter.c Junio C Hamano
2021-01-30  1:28   ` Junio C Hamano
2021-01-30 19:15     ` Hariom verma
2021-01-30 20:20     ` Junio C Hamano
2021-02-06  9:15   ` [PATCH v3 " Hariom Verma via GitGitGadget
2021-02-06  9:15     ` [PATCH v3 1/3] pretty.c: refactor trailer logic to `format_set_trailers_options()` Hariom Verma via GitGitGadget
2021-02-06  9:15     ` [PATCH v3 2/3] pretty.c: capture invalid trailer argument Hariom Verma via GitGitGadget
2021-02-06  9:15     ` [PATCH v3 3/3] ref-filter: use pretty.c logic for trailers Hariom Verma via GitGitGadget
2021-02-07  5:45       ` Junio C Hamano
2021-02-07 12:06         ` Hariom verma [this message]
2021-02-07 18:19           ` Junio C Hamano
2021-02-07 19:38             ` Hariom verma
2021-02-07 20:09               ` Junio C Hamano
2021-02-08 17:07                 ` Hariom verma
2021-02-08 18:29                   ` Junio C Hamano
     [not found]                     ` <xmqqlfby5o9h.fsf@gitster.c.googlers.com>
2021-02-08 23:43                       ` brian m. carlson
2021-02-09  3:04                       ` brian m. carlson
2021-02-09 20:54                         ` Junio C Hamano
2021-02-07  3:33     ` [PATCH v3 0/3] Unify trailers formatting logic for pretty.c and ref-filter.c Junio C Hamano
2021-02-07  5:06       ` Junio C Hamano
2021-02-13  1:52     ` [PATCH v4 0/4] " Hariom Verma via GitGitGadget
2021-02-13  1:52       ` [PATCH v4 1/4] t6300: use function to test trailer options Hariom Verma via GitGitGadget
2021-02-13  1:52       ` [PATCH v4 2/4] pretty.c: refactor trailer logic to `format_set_trailers_options()` Hariom Verma via GitGitGadget
2021-02-13  1:52       ` [PATCH v4 3/4] pretty.c: capture invalid trailer argument Hariom Verma via GitGitGadget
2021-02-13  1:52       ` [PATCH v4 4/4] ref-filter: use pretty.c logic for trailers Hariom Verma via GitGitGadget

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='CA+CkUQ9-OCiEkMDRTpyF3rp-g1mSSzn4s9MgqJZ2BJY=XJCoEw@mail.gmail.com' \
    --to=hariom18599@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 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).