Am 08.03.2010 15:32, schrieb Nguyen Thai Ngoc Duy: > On 3/8/10, René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> 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é -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html