From: Will Palmer <wmpalmer@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com, peff@peff.net
Subject: Re: [PATCH v2 2/3] pretty: make %H/%h dependent on --abbrev[-commit]
Date: Mon, 26 Apr 2010 08:47:54 +0100 [thread overview]
Message-ID: <u2i5b9751661004260047n168ad87bx6083fc201bfb21d9@mail.gmail.com> (raw)
In-Reply-To: <20100426031012.GA29953@progeny.tock>
> I agree that this is the right to do, since this is how the built-in
> formats work (the ‘commit ...’ line follows the semantics of your %H,
> and ‘Merge: ...’ line your %p, for example).
>
> Documentation and tests?
Tests, noted. I'll include some in the next version of the patch.
As for documentation, I'm not entirely sure what to add, as it seemed
like the change
merely implements what I would expect when reading the docs for
git-log. Still, noted.
I'll stick a short note in each of %H, %h, %P, %p, and %t
> Shortlog doesn’t print commit hashes, does it?
Shortlog accepts --format, though this doesn't seem to be documented
(if I type "man" and search
for "format"), so perhaps it should be.
>
>> diff --git a/commit.h b/commit.h
>> index b6caf91..7a476a0 100644
>> --- a/commit.h
>> +++ b/commit.h
>> @@ -72,6 +72,7 @@ struct pretty_print_context
>> int need_8bit_cte;
>> int show_notes;
>> int use_color;
>> + int abbrev_commit;
>> struct reflog_walk_info *reflog_info;
>> };
>>
>
> nitpick: I’d stick this up with abbrev and maybe add a comment to
> explain their distinct uses.
Noted. Thanks
>
>> diff --git a/log-tree.c b/log-tree.c
>> index 6bb4748..0a2309c 100644
>> --- a/log-tree.c
>> +++ b/log-tree.c
>> @@ -282,6 +282,8 @@ void show_log(struct rev_info *opt)
>> int abbrev_commit = opt->abbrev_commit ? opt->abbrev : 40;
>> const char *extra_headers = opt->extra_headers;
>> struct pretty_print_context ctx = {0};
>> + ctx.abbrev = opt->abbrev;
>> + ctx.abbrev_commit = opt->abbrev_commit;
>> ctx.use_color = DIFF_OPT_TST(&opt->diffopt, COLOR_DIFF);
>>
>> opt->loginfo = NULL;
>
> There is a
>
> ctx.abbrev = opt->diffopt.abbrev;
>
> later in the same function; how do these interact?
I hadn't caught that. My guess: stupidly doing the same thing twice.
I'll double-check,
and take out one of them if that's the case.
What all this
has shown me is that there are really too many ways to specify "context when
printing information about a commit". I don't like it, and the lot of
them can probably
be re-factored, perhaps by getting rid of pretty_context and passing
rev_info around
everywhere. I don't know the full implications of that and it seems
outside the scope
of this change.
>
>> @@ -741,24 +744,29 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
> [...]
>> strbuf_addstr(sb, find_unique_abbrev(
>> - p->item->object.sha1, DEFAULT_ABBREV));
>> + p->item->object.sha1,
>> + c->pretty_ctx->abbrev));
>
> nitpick: the new indentation makes these look like parameters to
> strbuf_addstr.
Noted. I'll restore the extra indent, which I had assumed was a typo.
>
> Here’s an alternative implementation of the more controversial half of
> your patch, for your amusement. The big downside is that it requires
> one to specify --abbrev-commit before the --format option.
>
> Thanks for the pleasant read.
>
> Jonathan
>
> diff --git a/pretty.c b/pretty.c
> index 7cb3a2a..1008a41 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -12,10 +12,31 @@
>
> static char *user_format;
>
> +static void abbreviate_commit_hashes(char *fmt)
> +{
> + char *p;
> + for (p = fmt; p != NULL; p = strchr(p + 1, '%')) {
> + p++;
> + switch (*p) {
> + case 'H':
> + *p = 'h';
> + break;
> + case 'P':
> + *p = 'p';
> + break;
> + case 'T':
> + default:
> + break;
> + }
> + }
> +}
> +
> static void save_user_format(struct rev_info *rev, const char *cp, int is_tformat)
> {
> free(user_format);
> user_format = xstrdup(cp);
> + if (rev->abbrev_commit)
> + abbreviate_commit_hashes(user_format);
> if (is_tformat)
> rev->use_terminator = 1;
> rev->commit_format = CMIT_FMT_USERFORMAT;
>
I had been thinking that this wouldn't be safe, but then that was my
being overly-cautious:
it's just been xstrdup()ed, so what we're parsing is ours, no real
reason not to do it.
I think the "must be specified after --abbrev-commit" is a rather
large nail, though. If you work
out the bugs mentioned by Jeff King, and it works, I'll stick it in
there, as I don't like
falling through case statements any more than the next guy. (well,
maybe a little more than
the next guy).
Thanks for the review!
-- Will Palmer
next prev parent reply other threads:[~2010-04-26 7:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-25 21:56 [PATCH v2 0/3] pretty: format aliases Will Palmer
2010-04-25 21:56 ` [PATCH v2 1/3] pretty: add conditional %C?colorname placeholders Will Palmer
2010-04-25 21:56 ` [PATCH v2 2/3] pretty: make %H/%h dependent on --abbrev[-commit] Will Palmer
2010-04-25 21:56 ` [PATCH v2 3/3] pretty: add aliases for pretty formats Will Palmer
2010-04-26 7:25 ` Jonathan Nieder
2010-04-26 8:15 ` Will Palmer
2010-04-26 22:11 ` Will Palmer
2010-04-26 3:11 ` [PATCH v2 2/3] pretty: make %H/%h dependent on --abbrev[-commit] Jonathan Nieder
2010-04-26 3:31 ` Jeff King
2010-04-26 3:38 ` Jonathan Nieder
2010-04-26 3:41 ` Jonathan Nieder
2010-04-26 3:45 ` Jeff King
2010-04-26 3:42 ` Jeff King
2010-04-26 7:47 ` Will Palmer [this message]
2010-04-26 9:53 ` Jonathan Nieder
2010-04-26 9:58 ` [PATCH 1/4] t4201 (shortlog): guard setup with test_expect_success Jonathan Nieder
2010-04-26 9:59 ` [PATCH 2/4] t4201 (shortlog): Test output format with multiple authors Jonathan Nieder
2010-04-26 9:59 ` [PATCH 3/4] shortlog: Document and test --format option Jonathan Nieder
2010-04-26 10:00 ` [PATCH 4/4] pretty: Respect --abbrev option Jonathan Nieder
2010-04-26 10:13 ` [PATCH v2 2/3] pretty: make %H/%h dependent on --abbrev[-commit] Will Palmer
2010-04-26 10:19 ` Jonathan Nieder
2010-04-26 10:23 ` Will Palmer
2010-04-26 10:28 ` Jonathan Nieder
2010-04-26 2:13 ` [PATCH v2 1/3] pretty: add conditional %C?colorname placeholders Jonathan Nieder
2010-04-26 3:26 ` Jeff King
2010-04-26 4:14 ` Jonathan Nieder
2010-04-26 14:28 ` Jeff King
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=u2i5b9751661004260047n168ad87bx6083fc201bfb21d9@mail.gmail.com \
--to=wmpalmer@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=peff@peff.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.
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).