Re: [PATCH 00/12] Support columinized output in tag/branch/ls-files/grep

["René Scharfe" <rene.scharfe@lsrfire.ath.cx>]

Am 08.03.2010 15:32, schrieb Nguyen Thai Ngoc Duy:
> On 3/8/10, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>>  I'm not so sure about the interface, though.  Does the task really
>>  warrant adding a new git command?
> 
> Several reasons:
>  - Can be reused outside of git (I was surprised Solaris did not have "column")

Granted, we have a precedent: git stripspace.  But I don't like that
one, either. ;)  If it's not specific to git, then it should not be a
git command.

Perhaps name it git-column--helper, so that it can still be used by git
commands that are implemented as scripts?

>  - Easier to test

Name it test-column?

>  - Minimum code change in modifed commands

OK, forking out is easy, but replacing printf() calls with calls to feed
the columnizer shouldn't be _that_ intrusive, either.

>  - I can play with more complicated column layout, with minimum code
> change in git (ok, that's the third reason).

This is possible regardless of the way how the columnizer is invoked if
its full functionality is exposed through the command line parameter.

With "more complicated", do you perhaps mean what GNU ls does, namely
having non-uniform column widths?  I never consciously noticed that it
actually goes out of its way to cram as may columns on the screen as
possible, it just feels so natural. :)

>>  If a --column parameter is added, I think it should expose the full
>>  range of options, i.e. fill columns first (ls -C style), fill rows first
>>  (ls -x style) as well as off (ls -1 style) and auto.
> 
> Maybe an env variable would be better, so you can pass abitrary
> arguments to git-column. "--column=auto" should be supported, of
> course.

I don't see any benefit of an environment variable over config options.

René