Jeff King <peff@xxxxxxxx> writes: > On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote: > >> 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. >> 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". >> 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"). -- 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