Re: BUG. Git config pager when --edit

["Frans Klaver" <fransklaver@gmail.com>]

On Mon, 07 Nov 2011 18:18:00 +0100, Jeff King <peff@peff.net> wrote:

>> I was actually hoping that you won't go that route, but the route to  
>> push
>> further to decide/spawn pager as late as possible. Clearly no sane  
>> person
>> would want to run --edit subcommand under pager and "pager.config =  
>> less"
>> should just be ignored in such a case.
>
> The problem with that is that it dumps the responsibility for running
> the pager to every subcommand. For builtins, we can have a flag that
> says "respect the pager.log config" or "foo will handle this itself;
> don't respect pager.tag".
>
> But what about externals? If "pager.stash" does nothing in git.c, and
> leaves it to "git-stash.sh" to start the pager if and when it's
> appropriate, then what about my personal "git-foo" that I drop into my
> PATH? Now I can't use "config.foo" without carrying code to do so in my
> external command.
>
> Maybe that's an OK tradeoff. But it's more of a pain for existing
> scripts, and it's not backwards compatible. What do you think?

For both cases there's something to say. In any new design I might dump  
the responsibility on the external, but I would prefer to keep the  
decision logic centralized. But as I understand, removing the  
responsibility from git.c is going to require a whole bunch of other  
changes to get the pager functional again in the scripts. So if there is a  
somewhat decent way to be sure about whether or not to use the pager (i.e.  
no editing) in git.c, why not keep it there? If, on the other hand, the  
code is going to turn out to be a big hack, I'd say move it out.

Frans