On Mon, Sep 19, 2016 at 09:03:05AM -0700, Junio C Hamano wrote:
> Anatoly Borodin <anatoly.boro...@gmail.com> writes:
> >> I think, the pagination should be turned off when the editor is being
> >> called.
> This is a fun one. IIRC, we decide to spawn a pager and run our
> output via pipe thru it fairly early, even before we figure out
> which subcommand is being run (especially if you do "git -p
> subcommand"), which by definition is way before we know if that
> subcommand wants to let the user edit things with the editor.
Right. Once the pager is spawned, it is too late to change things (even
if we spawned the editor directed to /dev/tty, it would be racily
competing for input with the pager).
And this isn't really limited to the editor. It's more _annoying_ with
the editor, but really "pager.tag" does not make any sense to set right
now, because it is handled outside of the "tag" command entirely, and
doesn't know what mode the tag command will be running in. So it's
_also_ the wrong thing to do with "git tag foo", which doesn't run an
editor (but you don't tend to notice if you use "less -F" because the
pager just quits immediately).
So you really only want to page tag-listing (and the same for branch,
config, etc). A long time ago I had a patch to add "pager.tag.list", and
the tag command would decide whether and how to page after realizing it
was in listing mode. Looks like I did send it to the list:
though I think there are some rough edges (like handling "git stash
I also wonder if there are any commands that actually have more than one
sub-command. So another option would be to teach the main git.c a
blacklist of "do not respect pager config" commands (like tag), and then
tag itself could decide to respect pager.tag at the right moment.
I think that makes things worse for a third-party command, though; we
cannot know whether a script "git-foobar" dropped into the $PATH would
like us to respect pager.foobar or if it would prefer to decide itself