Junio C Hamano <gitster@xxxxxxxxx> writes:
> But at least with your series, "git column" is as invisible as git-sh-setup
> and git-stripspace by being marked as purehelpers, so your patch may be
> the best we could do. I dunno.
I finally realized the true reason why I was so reluctant to take this
series. If the series were presented like the following, I wouldn't have
had any problem:
There is a widely used program, "column", that takes a data stream
one-item-per-line as its input and produces columnar output. Some
lists we produce as our output, e.g. "git tag --list", are often too
tall and sufficiently narrow, that "git tag --list | column" is a
useful thing to do. The first patch in this series teaches "git tag
--list" to do just that but internally, so the user does not have to
pipe manually from the command line.
Luckily, "column" is a free software, and more importantly, it is
written modularly enough so that we can reuse its primary logic to
produce lines for columnar output without having to feed its input
from the standard input or drain its output directly to the standard
output. Build an API around its core, and plug that logic to "branch
--list", "help -a" and other commands.
But that is not the case.
Yes, there is "column" that comes with BSD, and I am not suggesting to gut
it and reuse its code, but by adding our own "git column" and implementing
it as a built-in internal, we are making it harder for the outside world
to benefit from our implementation, even when our "git column" some day
becomes polished enough to the point that people who are used to the BSD
"column" start to wish their "column" had extra features offered by "git
column", without swallowing "git" as a whole.
Come to think of it, that is really the same distaste I had against both
"diff --no-index" and "grep --no-index". We know adding our enhancements
over non-git versions of these programs is a better gift to the outside
world, but we instead added the --no-index mode to Git to only keep the
benefit to ourselves, because it is far easier for us to do so.
But I do not deeply care either way.
--
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