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

From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Mar 11, 2010, 21:13 UTC
Message-ID: <4B995D0C.2090000@lsrfire.ath.cx>
In-Reply-To: <fcaeb9bf1003091627p65ad6e60u4bbae2eb4e859f13@mail.gmail.com>

Am 10.03.2010 01:27, schrieb Nguyen Thai Ngoc Duy:

Show 23 quoted lines

> On 3/9/10, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>>  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. :)
> 
> That. And aligned grep output like this
> 
> pclouds@do ~/w/git/builtin $ git grep -n 38
> count-objects.c  |  35 |                if (cp - ent->d_name != 38)
> count-objects.c  |  39 |                        memcpy(path + len + 3,
> ent->d_name, 38);
> count-objects.c  |  59 |                memcpy(hex+2, ent->d_name, 38);
> fsck.c           | 405 |                if (strlen(de->d_name) == 38) {
> gc.c             | 112 |                if (strspn(ent->d_name,
> "0123456789abcdef") != 38 ||
> gc.c             | 113 |                    ent->d_name[38] != '\0')
> prune-packed.c   |  24 |                if (strlen(de->d_name) != 38)
> prune-packed.c   |  26 |                memcpy(hex+2, de->d_name, 38);
> prune-packed.c   |  31 |                memcpy(pathname + len, de->d_name, 38);
> prune.c          |  64 |                if (strlen(de->d_name) == 38) {
> receive-pack.c   | 588 |        char hdr_arg[38];
> upload-archive.c |  86 |        char buf[16384];

Hmm, I'm not sure that this columnizing is very useful in this instance.
 You can more easily compare the line numbers and the indent level of
the hits, but both pieces of information are only useful in the context
of the file, so this easier comparison doesn't buy you much.

Another possible use might be the list of untracked files shown by status and commit, by the way.

Show 11 quoted lines

>> I don't see any benefit of an environment variable over config options.
> 
> Currently we may pass --column=<foo> from a porcelain to "git column
> --mode=<foo>", <foo> could be column first, or row first, or either
> with non-uniform columns (not implemented yet). We can also pass other
> things to "git column". Putting everything in "<foo>" is OK, although
> looks ugly. In my private tree, I also have "git column
> --min-rows/--max-items" that forces the columnizer to one column mode
> if:
>  - there will be only one or two rows after columnized, too wide
> screen for example (--min-rows)

Well, I can't imagine when I would want to use this option. If I'm OK with n + 100 items being displayed in x columns, I'd certainly be OK with n items being displayed the same way, even if they only take up a single row.

>  - too many lines and the layout has not been fixed, so nothing gets
> printed (--max-items). Forcing back to one column mode to stop wait
> time.

Interesting idea, but I'm not sure if I'd want to use it, too. Best effort pretty-printing combines fast output and optimized display at first glance. However, if there are lots of items then the user would benefit the most from having them columnized.

If it takes too long to show the first line of output (since the columnizer needs to wait for all items to be generated) then the command should only columnize on request.

René