Han-Wen Nienhuys wrote:
> As another example:

The recently posted patch documenting is an improvement, but why not

add an option so you can do
  --format 'committer %c\nauthor %a\n'
this catches all combinations, and is easier for scripting.
Right now, I have some scripts that have to munge log output with

regular expressions to strip out the "author:"  prefixes.
--

 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
-

With this patch,
$ git show -s \

	--pretty=format:'  Ze komit %h woss%n  dunn buy ze great %an'
shows something like
  Ze komit 04c5c88 woss

  dunn buy ze great Junio C Hamano
The supported placeholders are:
	'%H': commit hash

	'%h': abbreviated commit hash

	'%T': tree hash

	'%t': abbreviated tree hash

	'%P': parent hashes

	'%p': abbreviated parent hashes

	'%an': author name

	'%ae': author email

	'%ad': author date

	'%aD': author date, RFC2822 style

	'%ar': author date, relative

	'%at': author date, UNIX timestamp

	'%cn': committer name

	'%ce': committer email

	'%cd': committer date

	'%cD': committer date, RFC2822 style

	'%cr': committer date, relative

	'%ct': committer date, UNIX timestamp

	'%e': encoding

	'%s': subject

	'%b': body

	'%Cred': switch color to red

	'%Cgreen': switch color to green

	'%Cblue': switch color to blue

	'%Creset': reset color

	'%n': newline
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

---
	On Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:
	> The recently posted patch documenting is an improvement, but why

	> not add an option so you can do

	>

	>   --format 'committer %c\nauthor %a\n'

	>

	> this catches all combinations, and is easier for scripting.
	So, I overcame my laziness after 91 days...
	Of course, this is not as efficient as it could be: it _will_ get

	_all_ variables from the commit, even if not needed. However, I

	don't think that it matters in reality.
	BTW I have not found any implementation of xstrndup(), so I let it

	be static.
 Documentation/pretty-formats.txt |   44 +++++++++

 commit.c                         |  195 ++++++++++++++++++++++++++++++++++++++

 commit.h                         |    1 +

 log-tree.c                       |    2 +-

 4 files changed, 241 insertions(+), 1 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt

index fb0b0b9..2fe6c31 100644

--- a/Documentation/pretty-formats.txt

+++ b/Do...
[ message continues ]

Hmmm.  Would we want to make them somehow interoperable with

git-for-each-ref format atoms?
Also, it _might_ be worthwhile to do something like "%+4b"

which means "indent each line of this field with 4 spaces", for
Hmmm.  I strongly suspect that we would want to reuse code to
Thanks.
-

Hi,
Vy, it iss korrekt Churmen Inklish [Translation: Why, it is correct 
But those placeholders are so long! Not even GNU date supports such long 
This would be easy, methink, to teach to interpolate().
Maybe I can overcome my laziness, and extend interpolate() so that it can

actually call callbacks with callback data...
Alternatively, I could imitate for-each-ref, and roll my own

interpolate()? :-)
Ciao,

Dscho
-

What I was hinting at was to fix (or extend) for-each-ref to
Nah, if you feel it is too much work, I trust your judgement (I

do not recall details of how interpolate.c does its thing).  I

do not think it's worth it.
-

Hi,
Sure, it _would_ be nice to let interpolate call back, instead of having

to fill a table with static strings (xstrdup()ing them, no less).
However, I want to go play Snooker tonight, so this is up-for-grabs.
Ciao,

Dscho
-

nitpick:
  \n
for newline would be nice. Similar for backslash, formfeed, alarm, etc.
--

 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

-

Hi,
Yes, I thought about that. But it would change behaviour (even if I don't

think it would do serious damage; the only user of interpolate.[ch] I saw

is git-daemon, and that does not need \n, I guess).
Besides, "%n" is
- more consistent,

- date(1) does it the same way, and

- you can put BS, FF, AL, etc. into the format string before passing

  it as an option to git; git does not have to help you there.
Ciao,

Dscho
-

Other tools that come to mind, rpm and clearcase use \n vfor newline in the

format argument, which is good because I can guess that even without looking

at the documentation. %n I'd guess would be for a number of some kind, e..g.

They are hard to type in shells and even harder in gui's.
-- robin

-

Hi,
You would not do that all that often, but rather write a script. Even the

config format allows for inclusion of special characters, so aliases

should be fine.
Ciao,

Dscho
-

Hi,
Yes, it would be easier for scripting, and it would probably be relatively

easy, what with the addition of interpolate.[ch] to git. However, it is

work, and I am lazy.
What information would you like, anyway? IOW can you provide me with a

list like this:
%c	committer

%a	author

%d	committer_date

...
Ciao,

Dscho
-

Lazy is good when the details should not matter.  If some people

are scripting, they are fully capable of reading raw or fuller.
-