Re: [PATCH] grep: --full-tree

Jeff King [off-list ref] writes:

On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:

quoted

Guess what.  I have a similar problem, only it is that my "git status" 
output is _always_ too long, so I always have to page it.

Once upon a time, Junio applied a patch that implied -p with status.  I 
was overjoyed.  He reverted that patch later.  Yes, exactly.

It would have been more fair to me if Dscho said "He had to revert", to
hint that it was not due to me changing the preference left and right on a
whim.

quoted

So I end up doing "git config --global ps '-p status'" on every new 

If only somebody had written a "pager.status" configuration variable,
you could use that. Oh wait. I did. And it shipped in v1.6.0.

Nice try but, "grep" and "status" are apples and oranges comparision.

A "status" command that pages or does not page the output only when
spitting out to a terminal won't hurt somebody who helps another with the
configuration set differently, as much as a "grep" that shows or not shows
matches from other parts of the tree would, and when used by a script to
make a decision based on the output, the caller has to capture the output
first, and unless the caller drives "status" via pty, e.g. using "expect",
paging behaviour will be disabled no matter what the configuration setting
is.

So neither "it would hurt people who help others" nor "it would hurt
scripts" would apply to "status".  But both would apply to "grep".

quoted

The further benefit is that we stop talking about breaking backwards 
compatibility, and we stop talking about making it hard for Git experts to 
help newbies.

I guess you missed the part of the thread where I already discussed
this. It was here:

  http://article.gmane.org/gmane.comp.version-control.git/133672

This was a very good summary, and was one of the reasons that made me
reconsider placing too much weight on "it would hurt people who help
others" (but not on "it would hurt scripts").