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

From: Theodore Ts'o <tytso@mit.edu>
Date: Jul 10, 2016, 23:28 UTC
Message-ID: <20160710232809.GM26097@thunk.org>
In-Reply-To: <CACsJy8CSqjTztFu1fOXqyS1jXjt=D_pgAC4MXpnECAcu+dRu2w@mail.gmail.com>

On Sun, Jul 10, 2016 at 06:05:31PM +0200, Duy Nguyen wrote:

Show 8 quoted lines

> 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.

Show 5 quoted lines

> 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