From: Jeff King <peff@peff.net>
To: Derek Moore <derek.p.moore@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Some PRETTY FORMATS format:<string> options don't work with git-archive export-subst $Format:$
Date: Thu, 9 Oct 2014 15:07:22 -0400 [thread overview]
Message-ID: <20141009190722.GA415@peff.net> (raw)
In-Reply-To: <CAMsgyKYKAUXamcGOtUi3Bq-u4B9JaG2sk-Gttf+A1U2mwhghrw@mail.gmail.com>
On Thu, Oct 09, 2014 at 12:42:39PM -0500, Derek Moore wrote:
> As far as I've tested it would seem only %N doesn't resolve inside of
> $Format:$, until I maybe do unit tests for this to identify any
> others.
Yes, %N is somewhat special in that the calling code needs to initialize
the notes tree itself. We can't just do it lazily when we see the first
%N because _which_ notes we show depends on other options (e.g., for
log, if you've used --notes-ref, --show-notes=..., etc).
So in theory you need something like 5b16360 (pretty: Initialize notes
if %N is used, 2010-04-13), but adapted for git-archive. The trick,
though, is that we do not even see the format string until we are
looking at a particular file with a $Format$ marker. So you'd have to
lazily initialize notes there (and if you want to support picking
specific notes refs, you'd have to teach git-archive new options to do
so[1]).
Here's a quick-and-dirty patch that makes the snippet you posted earlier
do what I think you expected. I haven't tested it beyond that, and am
not planning to push it forward myself, but please feel free to use it
as a basis for building a solution.
---
diff --git a/archive.c b/archive.c
index 952a659..3af781e 100644
--- a/archive.c
+++ b/archive.c
@@ -5,6 +5,7 @@
#include "archive.h"
#include "parse-options.h"
#include "unpack-trees.h"
+#include "notes.h"
static char const * const archive_usage[] = {
N_("git archive [options] <tree-ish> [<path>...]"),
@@ -38,6 +39,8 @@ static void format_subst(const struct commit *commit,
if (src == buf->buf)
to_free = strbuf_detach(buf, NULL);
for (;;) {
+ struct userformat_want ufw = {0};
+ struct strbuf notes = STRBUF_INIT;
const char *b, *c;
b = memmem(src, len, "$Format:", 8);
@@ -50,10 +53,31 @@ static void format_subst(const struct commit *commit,
strbuf_reset(&fmt);
strbuf_add(&fmt, b + 8, c - b - 8);
+ userformat_find_requirements(fmt.buf, &ufw);
+ if (ufw.notes) {
+ static int initialized;
+ if (!initialized) {
+ init_display_notes(NULL);
+ initialized = 1;
+ }
+ format_display_notes(commit->object.sha1, ¬es,
+ get_log_output_encoding(), 1);
+ /*
+ * trim trailing newlines from note content, which is
+ * probably more appropriate for $Format$; should
+ * this actually remove internal newlines, too?
+ */
+ strbuf_rtrim(¬es);
+ }
+ ctx.notes_message = notes.buf;
+
strbuf_add(buf, src, b - src);
format_commit_message(commit, fmt.buf, buf, &ctx);
len -= c + 1 - src;
src = c + 1;
+
+ ctx.notes_message = NULL;
+ strbuf_release(¬es);
}
strbuf_add(buf, src, len);
strbuf_release(&fmt);
-Peff
[1] I think you could get pretty far using `git -c core.notesRef=foo` to
give ad-hoc config, as the notes code should use that as the
ultimate default. But I didn't try it.
next prev parent reply other threads:[~2014-10-09 19:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-09 15:56 Some PRETTY FORMATS format:<string> options don't work with git-archive export-subst $Format:$ Derek Moore
2014-10-09 17:42 ` Derek Moore
2014-10-09 19:07 ` Jeff King [this message]
2014-10-09 19:12 ` Derek Moore
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=20141009190722.GA415@peff.net \
--to=peff@peff.net \
--cc=derek.p.moore@gmail.com \
--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