On Tue, Aug 16, 2011 at 12:10:45PM +0200, Ingo Brückl wrote: > > http://thread.gmane.org/gmane.comp.version-control.git/161756/focus=161771 > > Actually, I only wanted to change the stash list behavior (but better should > have used $(git config --get pager.stash.list) for that). Unfortunately, it > is impossible then to force the pager with --paginate again. > > > I think what it really needs is more testing to see if looking at the > > config then has any unintended side effects. > > Yours surely is a far better approach, although it only can handle the main > command (stash), not the sub-command (list), but this is totally in > accordance with everything else in git. Yeah, that is a general problem with git's pager handling. We only have one context: a single git command. But some commands may have multiple subcommands, and a pager only makes sense for some of them. You've run into it for "stash show", but it is no different than something like "git branch". You might want the list of branches to go through a pager, but almost certainly not branch creation or deletion operations. I think something like pager.stash.list is the right way forward. But your patch by itself isn't enough. It only handles the negative case. Setting "pager.stash.list" to "true" would do nothing. > With "pager.stash false" (which would then require --paginate for a lot of > stash commands), I found that a paginated output of 'git -p stash show -p' > loses the diff colors, but that seems unrelated to your patch. It still is > strange though. We auto-detect whether to use colors based on whether we are outputting to a terminal or not. If we start the pager ourselves, we will also output colors (unless color.pager is false). I suspect the "pager in use" flag is not making it to the external command. -Peff -- 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