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
next prev 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.