git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Adam Simpkins <adam@adamsimpkins.net>, git@vger.kernel.org
Subject: Re: [PATCH 2/4] log and rev-list: Fixed newline termination issues with --graph
Date: Mon, 07 Apr 2008 06:19:25 -0700 (PDT)	[thread overview]
Message-ID: <m3hcedu7kd.fsf@localhost.localdomain> (raw)
In-Reply-To: <7vwsnaoxlz.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > I suspect that --pretty=format: (i.e. userformat) should have a way to
> > explicitly tell which is wanted.  Perhaps we can keep the separator
> > semantics not to break existing users, and introduce a dummy expand item
> > (say, '%_') and when it appears in the pattern it would ask for the
> > terminator semantics instead?
> >
> > In any case, I'm happy to see that somebody started looking into this, as
> > this "separator vs terminator" issue in userformat has been nagging me for
> > quite a while.  It might be good idea to have the change independently
> > from the graph extension first and then build the graph stuff on top of
> > the solidified base.  I dunno...
> 
> Some alternatives to specify terminator semantics I considered are:
> 
>  (1) Presence of %_ in "--pretty=format:..." triggers terminator
>      semantics and %_ itself interpolates an empty string; otherwise
>      separator semantics is used.

Or %_ might interpolate to _single_ separator, swallowing all
separators that follows it (something like collapsing whitespace).
Either that, or %_ interpolate to separator value, and %*_ collapses
separators (terminators).
 
Bit less hacky, bit more geeky.

>  (2) Presence of %n in "--pretty=format:..." means a multi-line output and
>      uses separator as before; lack of %n means it is a one-line format
>      and uses terminator.

I guess that literal newline in format would also mean multi-line
output.  Also '%b' (body) should mean multi-line output.


BTW. rpm uses [% ... ] to iterate over a set of (parallel) arrays
in --queryformat, which is a bit similar to --pretty=format:<fmt>,
e.g. 'rpm -q --queryformat "[%-50{FILENAMES} %10{FILESIZES}\n]'

BTW2. git-for-each-ref uses _different_ kind of format, %(<name>) and
not %<char>.

>  (3) A new option --pretty=tformat:... (i.e. tformat instead of format)
>      means LF (or NUL) is used as terminator instead of separator;
> 
>  (4) A new syntax --pretty=format/... (i.e. slash instead of the usual
>      colon) means LF (or NUL) is used as terminator instead of separator;
> 
> The first one is what I suggested in the message, but it feels somewhat
> hacky.  I suspect that the second one would catch 99% of the cases, but it
> is DWIM and it is known that DWIM can go wrong.  I favor design along
> the lines of (3) or (4), which I think would be much cleaner.
> 
> I however do not particularly like either "tformat" which is a non-word,
> nor ":" vs "/" whose differences do not intuitively translate to
> "separator vs terminator" distinction.

"|" instead of ":" wouldn't be a good idea?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

  parent reply	other threads:[~2008-04-07 13:20 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-06 18:42 [PATCH 1/4] Add history graph API Adam Simpkins
2008-04-06 18:42 ` [PATCH 2/4] graph API: Added additional utility functions to the " Adam Simpkins
2008-04-06 18:42   ` [PATCH 3/4] git log and git rev-list: Add --graph option Adam Simpkins
2008-04-06 18:42     ` [PATCH 4/4] git log: Updated --graph to work even when the commit list is pruned Adam Simpkins
2008-04-06 21:47       ` [PATCH 5/5] Document the new --graph option for log and rev-list Adam Simpkins
2008-04-07  8:01         ` [PATCH 1/4] graph API: Fixed coding style problems Adam Simpkins
2008-04-07  8:01           ` [PATCH 2/4] log and rev-list: Fixed newline termination issues with --graph Adam Simpkins
2008-04-07  8:01             ` [PATCH 3/4] log and rev-list: Fix --graph output with --pretty=email Adam Simpkins
2008-04-07  8:01               ` [PATCH 4/4] log and rev-list: Improve --graph output when commits have been pruned Adam Simpkins
2008-04-07  8:21             ` [PATCH 2/4] log and rev-list: Fixed newline termination issues with --graph Junio C Hamano
2008-04-07  8:52               ` Junio C Hamano
2008-04-07 13:17                 ` Jeff King
2008-04-07 17:43                   ` Junio C Hamano
2008-04-07 19:01                     ` Adam Simpkins
2008-04-07 13:19                 ` Jakub Narebski [this message]
2008-04-08  0:11                 ` Junio C Hamano
2008-04-08  0:25                   ` Govind Salinas
2008-04-08  0:58                     ` Junio C Hamano
2008-04-06 21:15     ` [PATCH 3/4] git log and git rev-list: Add --graph option Teemu Likonen
2008-04-06 22:51       ` Adam Simpkins
2008-04-06 20:30 ` [PATCH 1/4] Add history graph API Teemu Likonen
2008-04-06 21:44   ` Adam Simpkins
2008-04-06 20:42 ` Johannes Schindelin
2008-04-06 22:47   ` Adam Simpkins
2008-04-07  5:24     ` Teemu Likonen
2008-04-07  8:34       ` Adam Simpkins
2008-04-07  8:56         ` Teemu Likonen
2008-04-06 21:06 ` Johannes Schindelin
2008-04-06 22:04   ` Adam Simpkins
2008-04-06 22:15     ` Johannes Schindelin
2008-04-06 22:58       ` Adam Simpkins
2008-04-07 16:15       ` Linus Torvalds
2008-04-07  3:12     ` Junio C Hamano
2008-04-06 21:25 ` [PATCH] bash: Add command line completion of --graph (git log) Teemu Likonen
2008-04-07 12:25   ` [PATCH v2] bash: Add more command line option completions for 'git log' Teemu Likonen
2008-04-07  7:26 ` [PATCH 1/4] Add history graph API Teemu Likonen
2008-04-07  8:06   ` Adam Simpkins

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=m3hcedu7kd.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=adam@adamsimpkins.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).