Re: [PATCH] pretty: add format specifiers: %gr, %gt, %gI, gi

[Theodore Ts'o <tytso@mit.edu>]

On Sun, Jul 10, 2016 at 06:05:31PM +0200, Duy Nguyen wrote:
> On Sun, Jul 10, 2016 at 4:26 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> > One other long-term thought.  Maybe past a certain point, we should
> > just make it easy to get the data from git-log into a perl or pythons
> > script, where it becomes possible to do conditionals, more flexible
> > padding rules, etc.  So some kind of --format=yaml or --format=json
> > sort of thing.
> 
> I thought libgit2 would already give you all the information you need.

libgit2 isn't really all that useful if you are writing a shell
script.  Even from perl or python, setting up SWIG bindings and then
linking libgit2 into perl or python isn't exactly the most convenient
thing in the world.

Also, my original use case was something I could drop into
~/.gitconfig as an git alias, although I don't object to having a
separate shell script if that was the only way to do what I wanted.

> Putting everything in columns is my thing :) We can do something like
> that. It should not be so hard to put titles on top and draw some
> lines, I think, if you set fixed column widths. I'm just not sure if
> it will be really helpful. What sort of use case do you have in mind
> (besides git-log --oneline with customizable columns)?

I didn't; it was the example of something which was over the top.  :-)

That being said, it is nice if you can have columns where the
pretty-printer auto-sizes the column widths.  Most databases which
have a REP loop for SQL statements will do this, as does gcloud's
--format='table[box]...' scheme.  That unfortunately means a two-pass
scheme, although I could imagine something which looks at the first N
commits to be printed, figured out column widths, and then either
truncates or autowraps if there are commits after the first N which
have require a field wider than what was autosized.

It may be too much to think that all of this should be in git's core
implementation, though.  This is where it might be simpler to easily
get the information into perl or python, and then do the final
formatting in perl/pyhton.  Hence my suggestion for some kind of yaml
or json format.  Although I suppose a CPAN or Python Module that
dlopen's libgit2 could also work, so long as it was super-easy for
someone who just wants to create a git-log like report can just do so
without having to create their own C program or C language bindings to
libgit2....

					- Ted