Re: [PATCH 0/4] git --paginate: do not commit pager choice too early

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 14, 2010, 20:36 UTC
Message-ID: <7v630hyf5r.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vpqzacs3h.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 9 quoted lines

> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Patch is against master.  There is a small semantic conflict with
>> jn/grep-open: SIMPLEPAGER should be changed to SIMPLEPAGERTTY in the
>> prerequisites for the test_default_pager function.  Please let me
>> know if I should push a merge commit to help resolve that.
>
> Thanks for advance warning; please double check the merge result in 'pu'
> when I push it out...

I hate an enumeration that pretends to be exhausitive but is not.

    So delay the pager startup when possible:
    
    1. run_argv() already commits pager choice inside run_builtin() if a
       command is found.  For commands that use RUN_SETUP, waiting until
       then fixes the problem described above: once git knows where to
       look, it happily respects the core.pager setting.

... and for commands that do not use RUN_SETUP, what happens?

    2. list_common_cmds_help() prints out 29 lines and exits....
    3. help_unknown_cmd() prints out a few lines to stderr.  It is not
       important to paginate this, so don’t.

Missing from the above enumeration are are external commands. They depend on commit_pager_choice() to be called before execv_dashed_external() gets called. For example, "git -p request-pull $args" no longer works with this patch.

Sigh..