git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git <git@vger.kernel.org>, Jeff King <peff@peff.net>,
	Taylor Blau <me@ttaylorr.com>
Subject: Re: [PATCH] rev-list: add option for --pretty without header
Date: Fri, 9 Jul 2021 10:01:46 +0200	[thread overview]
Message-ID: <CAP8UFD0t0=us1MWHTtEvVhNhWB1P6Q5gp-6v5XVGLBVeZ5RYKg@mail.gmail.com> (raw)
In-Reply-To: <20210706224321.14371-1-sandals@crustytoothpaste.net>

On Wed, Jul 7, 2021 at 12:47 AM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> In general, we encourage users to use plumbing commands, like git
> rev-list, over porcelain commands, like git log, when scripting.
> However, git rev-list has one glaring problem that prevents it from
> being used in certain cases: when --pretty is used, it always prints out
> a line containing "commit" and the object ID.

You say always, but it looks like it doesn't do it when
--pretty=oneline is used.

By the way this makes me think that the doc could be improved, because
it describes the format this way:

      •   online

              <hash> <title line>

      •   short

              commit <hash>
              Author: <author>

              <title line>

      •   reference

              <abbrev hash> (<title line>, <short author date>)

      •   email

              From <hash> <date>
              From: <author>
              Date: <author date>
              Subject: [PATCH] <title line>

              <full commit message>

while when --pretty=reference or --pretty=email is used the 'commit
<hash>' line is still printed despite not being shown in the doc.

> This makes it unsuitable
> for many scripting needs, and forces users to use git log instead.

I agree that it's annoying when using --pretty=format:'...'

> While we can't change this behavior for backwards compatibility, we can
> add an option to suppress this behavior, so let's do so, and call it
> "--no-commit-header".  Additionally, add the corresponding positive
> option to switch it back on.

It's not clear if this new option will remove the 'commit <hash>' line
when a builtin format like --pretty=short, --pretty=medium,
--pretty=reference or --pretty=email is used.

> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
> This has come up a lot on the list and I'm sure most of the regulars
> have run into it before.

Yeah, I did run into it before. Thanks for doing something about it!

> It came up at $DAYJOB and I said I intended to
> send a patch, so here it is.
>
> I chose --no-commit-header because --header is already taken.

Yeah, that looks like the most obvious option name.

>  --header::
>         Print the contents of the commit in raw-format; each record is
>         separated with a NUL character.
> +
> +--no-commit-header::
> +       Suppress the header line containing "commit" and the object ID printed before
> +       the specified format.

This might want to tell what happens with builtin formats.

> +--commit-header::
> +       Overrides a previous `--no-commit-header`.
>  endif::git-rev-list[]
>
>  --parents::

[...]

> diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
> index 35a2f62392..e68bf9f21c 100755
> --- a/t/t6006-rev-list-format.sh
> +++ b/t/t6006-rev-list-format.sh
> @@ -54,9 +54,15 @@ test_expect_success 'setup' '
>
>  # usage: test_format name format_string [failure] <expected_output
>  test_format () {
> +       local header_arg=
> +       if test "$1" = "--no-commit-header"
> +       then
> +               header_arg="--no-commit-header"
> +               shift
> +       fi
>         cat >expect.$1
>         test_expect_${3:-success} "format $1" "
> -               git rev-list --pretty=format:'$2' main >output.$1 &&
> +               git rev-list $header_arg --pretty=format:'$2' main >output.$1 &&
>                 test_cmp expect.$1 output.$1
>         "
>  }

It looks like the tests only check what happens in case
--pretty=format:'...' is used, but I wonder what the code does if a
builtin format is used.

  reply	other threads:[~2021-07-09  8:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-06 22:43 [PATCH] rev-list: add option for --pretty without header brian m. carlson
2021-07-09  8:01 ` Christian Couder [this message]
2021-07-09 15:44   ` Junio C Hamano
2021-07-11 17:02     ` brian m. carlson
2021-07-11 21:55 ` [PATCH v2] rev-list: add option for --pretty=format " brian m. carlson
2021-07-12  7:30   ` Christian Couder
2021-07-13  0:10     ` brian m. carlson
2021-07-12 18:13   ` Jeff King
2021-07-13  0:15     ` brian m. carlson

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP8UFD0t0=us1MWHTtEvVhNhWB1P6Q5gp-6v5XVGLBVeZ5RYKg@mail.gmail.com' \
    --to=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).