Re: BUG. Git config pager when --edit

On Mon, 07 Nov 2011 18:18:00 +0100, Jeff King [off-list ref] wrote:

quoted

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