git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Harry Jeffery <harry@exec64.co.uk>, git@vger.kernel.org
Subject: Re: [PATCH] pretty-format: add append line-feed format specifier
Date: Fri, 12 Sep 2014 00:49:01 -0400	[thread overview]
Message-ID: <20140912044901.GC15519@peff.net> (raw)
In-Reply-To: <xmqqtx4fgzqe.fsf@gitster.dls.corp.google.com>

On Wed, Sep 10, 2014 at 10:19:21AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Something like the patch below might work, but I didn't test it very
> > thoroughly (and note the comments, which might need dealing with). Maybe
> > it would make a sensible base for Harry to build on if he wants to
> > pursue this.
> >
> > With it, you can do:
> >
> >   git log --format='%h %s%if(%d,%n  Decoration:%d)' origin
> > ...
> > You could also make "%d" more flexible with it. We unconditionally
> > include the " (...)" wrapper when expanding it. But assuming we
> > introduced a "%D" that is _just_ the decoration names, you could do:
> >
> >   %if(%D, (%D))
> >
> > to get the same effect with much more flexibility.
> 
> Yup.
> 
> I do not think we need to go overboard to support nesting and stuff,
> let alone turing completeness ;-), especially when we are going to
> test the condition part only for emptyness.  Even with this simple
> patch, I sense that we are near a slipperly slope of wanting to add
> %unless(%d, ) or %ifelse(%d,%d, \(undefined\)), so I am not 100%
> convinced yet.

What compelled me is the fact that we already started down the slippery
slope with %+ and friends. Providing conditionals but then only allowing
certain characters seems weirdly limiting. But I guess it is all part of
the same slope.

I dunno. I wrote that original set of lua pretty-format patches to try
to stop the insanity once and for all. But I realized that I do not
actually want to do anything complicated with the output formats, and
"--oneline" and a few simple "--format" calls usually are enough. And if
I do want more, I pipe it into a perl script (typically using --format
to make it simple to parse).

We could also provide the data in some standard structured format like
JSON to make the "pipe to your language of choice" option easier on
people. But using custom --formats to do so is not that hard, and is way
more efficient than dumping all of the data.

-Peff

  reply	other threads:[~2014-09-12  4:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09 18:09 [PATCH] pretty-format: add append line-feed format specifier Harry Jeffery
2014-09-09 19:15 ` Junio C Hamano
2014-09-09 19:30   ` Harry Jeffery
2014-09-09 19:37     ` Junio C Hamano
2014-09-09 21:45       ` Jeff King
2014-09-09 22:17         ` Harry Jeffery
2014-09-09 22:31           ` Jeff King
2014-09-10 17:19         ` Junio C Hamano
2014-09-12  4:49           ` Jeff King [this message]
2014-09-12 16:36             ` Junio C Hamano

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=20140912044901.GC15519@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=harry@exec64.co.uk \
    /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).