From: kristofferhaugsbakk@fastmail.com
To: git@vger.kernel.org
Cc: Kristoffer Haugsbakk <code@khaugsbakk.name>
Subject: [PATCH 0/2] name-rev: learn --format=<pretty>
Date: Fri, 13 Mar 2026 17:03:36 +0100 [thread overview]
Message-ID: <CV_name-rev_--format.4ad@msgid.xyz> (raw)
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Topic name: kh/name-rev-pretty-format
Topic summary: Teach git-name-rev(1) a mode to pretty format revisions
instead of outputting symbolic names.
(See the second patch for details.)
The first patch is just for `CodingGuidelines`. Unrelated.
I have gone through three approaches: pretty print, `log-tree:
log_tree_commit`, and pretty print again. At first I was confused
when using `pretty_print_commit` because I couldn’t seem to get the same
output as git-log(1):
# for git-log(1)
git log --format=<pretty>
# for git-name-rev(1)
git rev-list HEAD |
git name-rev --format=<pretty> --annotate-stdin
Because there were some minor differences for a few things I tried:
• fuller: log has the `commit <commit>` header; pretty does not
• oneline: log has the oid; pretty does not
Then I tried `log_tree_commit`. But then I got some things that I didn’t
want. This function also didn’t fit in with the git-name-rev(1) processing
since it just dumps straight to standard out instead of allowing you to
accumulate things in a scratch buffer (strbuf). So then I went back to the
`pretty_print_commit` approach.
Notes are handled by reading the display refs. I can imagine that it would
be better for this command to use `--[no-]notes` arguments like the ones
that git-log(1) has for explicit control (without using env. variables).
[1/2] name-rev: wrap both blocks in braces
[2/2] name-rev: learn --format=<pretty>
Documentation/git-name-rev.adoc | 9 +++-
builtin/name-rev.c | 85 ++++++++++++++++++++++++++++-----
t/t6120-describe.sh | 58 ++++++++++++++++++++++
3 files changed, 139 insertions(+), 13 deletions(-)
base-commit: 67006b9db8b772423ad0706029286096307d2567
--
2.53.0.32.gf6228eaf9cc
next reply other threads:[~2026-03-13 16:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 16:03 kristofferhaugsbakk [this message]
2026-03-13 16:03 ` [PATCH 1/2] name-rev: wrap both blocks in braces kristofferhaugsbakk
2026-03-14 0:22 ` Junio C Hamano
2026-03-17 22:10 ` Kristoffer Haugsbakk
2026-03-13 16:03 ` [PATCH 2/2] name-rev: learn --format=<pretty> kristofferhaugsbakk
2026-03-14 0:22 ` Junio C Hamano
2026-03-17 22:07 ` Kristoffer Haugsbakk
2026-03-18 15:36 ` Kristoffer Haugsbakk
2026-03-20 13:09 ` [PATCH v2 0/2] " kristofferhaugsbakk
2026-03-20 13:09 ` [PATCH v2 1/2] name-rev: wrap both blocks in braces kristofferhaugsbakk
2026-03-20 13:09 ` [PATCH v2 2/2] name-rev: learn --format=<pretty> kristofferhaugsbakk
2026-03-20 15:25 ` D. Ben Knoble
2026-03-23 17:34 ` Kristoffer Haugsbakk
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=CV_name-rev_--format.4ad@msgid.xyz \
--to=kristofferhaugsbakk@fastmail.com \
--cc=code@khaugsbakk.name \
--cc=git@vger.kernel.org \
/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