On Mon, 07 Nov 2011 18:18:00 +0100, Jeff King <peff@xxxxxxxx> 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
--
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