From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>,
"Michael Dressel" <MichaelTiloDressel@t-online.de>,
git@vger.kernel.org
Subject: Re: [PATCH 3/3] add '%d' pretty format specifier to show decoration
Date: Thu, 04 Sep 2008 17:41:16 -0700 [thread overview]
Message-ID: <7v3akf1l1v.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20080905003710.GA17731@coredump.intra.peff.net> (Jeff King's message of "Thu, 4 Sep 2008 20:37:10 -0400")
Jeff King <peff@peff.net> writes:
> On Thu, Sep 04, 2008 at 05:28:13PM -0700, Junio C Hamano wrote:
>
>> > The whole series looks good to me, and I am happy if it is applied
>> > as-is. The only question I might raise is whether we want to use "%d"
>> > for this, or use something longer to anticipate a collision with other
>> > "d" words (I think you mentioned "describe" at one point).
>>
>> How about using "%d()" for this one, so that later enhancements can
>> specify their features inside parentheses?
>
> I am slightly opposed to that, just because it then is very inconsistent
> with the other formatting specifiers. I think it is worth introducing a
> new, consistent syntax, providing that syntax for all specifiers (e.g.,
> %(body), %(decorate)), and then saying "the existing %b, %d, et al are
> still available and will be available forever. BUT they will never grow
> the more interesting features like %(body:wrap=80) or
> %(decorate:delim=, ).
Ok, fair enough. Then it will be between "%d" vs "%(decorate)" for
today's three patches. If we do the former, then we will have one more in
the "existing %b %d et al" set when we do start working on extended
formats; if we do the latter, "existing" will have one less format, but we
have many "existing" ones already, and one more will not hurt that much in
the long run.
So let's take these patches as-is, unless somebody else have better ideas?
next prev parent reply other threads:[~2008-09-05 0:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-03 18:40 [PATCH 1/2] add '%d' pretty format specifier to show decoration Michael Dressel
2008-09-03 19:12 ` Jeff King
2008-09-03 20:10 ` Junio C Hamano
2008-09-03 20:36 ` Jeff King
2008-09-03 20:59 ` Junio C Hamano
2008-09-03 21:04 ` Jeff King
2008-09-03 22:06 ` René Scharfe
2008-09-04 3:51 ` Jeff King
2008-09-04 15:47 ` René Scharfe
2008-09-04 21:38 ` [PATCH 1/3] log: add load_ref_decorations() René Scharfe
2008-09-04 21:39 ` [PATCH 2/3] move load_ref_decorations() to log-tree.c and export it René Scharfe
2008-09-04 21:40 ` [PATCH 3/3] add '%d' pretty format specifier to show decoration René Scharfe
2008-09-05 0:11 ` Jeff King
2008-09-05 0:28 ` Junio C Hamano
2008-09-05 0:37 ` Jeff King
2008-09-05 0:41 ` Junio C Hamano [this message]
2008-09-05 18:38 ` Michael Dressel
2008-09-09 17:33 ` Michael Dressel
2008-09-09 20:15 ` René Scharfe
2008-09-05 16:14 ` René Scharfe
2008-09-03 19:17 ` [PATCH 1/2] " Jeff King
2008-09-03 20:06 ` Michael Dressel
2008-09-03 20:33 ` 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=7v3akf1l1v.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=MichaelTiloDressel@t-online.de \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=rene.scharfe@lsrfire.ath.cx \
/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).