git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin Ågren" <martin.agren@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Git Mailing List <git@vger.kernel.org>,
	hkleynhans@bloomberg.net, Thomas Gummerer <t.gummerer@gmail.com>
Subject: Re: [PATCH/DONOTAPPLY 0/4] first steps towards pager.foo.{command,enable}
Date: Tue, 7 Nov 2017 21:46:52 +0100	[thread overview]
Message-ID: <CAN0heSrgkjpt5MfMbc15L0z3M6ch3F3qBgCqEf7i6VOe73fWtg@mail.gmail.com> (raw)
In-Reply-To: <20171106104801.73n27fgmn43y6m3v@sigill.intra.peff.net>

On 6 November 2017 at 11:48, Jeff King <peff@peff.net> wrote:
> On Sun, Nov 05, 2017 at 12:58:18PM +0100, Martin Ågren wrote:
>> In particular, they do not teach `--paginate` to use the pager
>> configured by `pager.foo.command`. It is already now possible to use
>> `pager.foo` to say "I don't want you to page, but if I later give you
>> `pager.foo=true`, this is the pager I want you to use". That does not
>> work with `--paginate`, but this can all be explained -- indeed, we
>> document that `--paginate` overrules `pager.foo`.
>
> Hmm. I think the current behavior is actually buggy. I assume the
> documentation you mean is from git.txt:
>
>   --paginate::
>           Pipe all output into 'less' (or if set, $PAGER) if standard
>           output is a terminal.  This overrides the `pager.<cmd>`
>           configuration options (see the "Configuration Mechanism" section
>           below).

Yes, that's what I meant.

> That comes from 06300d9753 (git.1: Clarify the behavior of the
> --paginate option, 2010-02-14). But I think that commit was just trying
> to clarify that "--paginate" overrides the defaults and config, but not
> does say "always paginate".

Thanks for digging.

You're probably right that this was not intended. I think I put way too
much weight on the "s" in "options". I understood it as "both ways
pager.foo can be used". From the commit message you point to, it seems
that only the boolean-ness was intended. (The "s" probably refers to
pager.foo, pager.bar, ...)

>> If we teach `--paginate` to respect `pager.foo.command`, it seems that
>> we would either 1) introduce a small (and possibly hard to understand
>> and explain) difference between the old-style and the new-style
>> pager-configuration or 2) knowingly change the behavior of
>> `--paginate`
>> with `pager.foo` or 3) knowingly change the behavior of
>> `pager.foo=false` as documented in the first patch.

> I think I'm suggesting (2), then.

I think you're right. If this topic doesn't get picked up in the near
future (in London or elsewhere), I'll get back to this.

A final thought for whoever tackles this: Playing with something like
`git -c pager.log=$foo --paginate log` vs `git -c core.pager=$foo
--paginate log` might be helpful. Possibly $foo=cat could be
particularly interesting, I haven't thought hard about it.

Martin

  reply	other threads:[~2017-11-07 20:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 16:36 Git Open Source Weekend London 11th/12th November Thomas Gummerer
2017-11-04  9:28 ` Jeff King
2017-11-04 17:15   ` Philip Oakley
2017-11-05 11:58   ` [PATCH/DONOTAPPLY 0/4] first steps towards pager.foo.{command,enable} Martin Ågren
2017-11-05 11:58     ` [PATCH 1/4] t7006: document that `pager.foo` can be partially preserved Martin Ågren
2017-11-05 11:58     ` [PATCH 2/4] pager: refactor `pager_command_config()` Martin Ågren
2017-11-05 11:58     ` [PATCH 3/4] pager: introduce `pager.*.command` and `.enable` Martin Ågren
2017-11-05 11:58     ` [PATCH 4/4] pager: make `pager.foo.command` imply `.enable=true` Martin Ågren
2017-11-06 10:48     ` [PATCH/DONOTAPPLY 0/4] first steps towards pager.foo.{command,enable} Jeff King
2017-11-07 20:46       ` Martin Ågren [this message]
2017-11-05 12:42 ` Git Open Source Weekend London 11th/12th November Patrick Steinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAN0heSrgkjpt5MfMbc15L0z3M6ch3F3qBgCqEf7i6VOe73fWtg@mail.gmail.com \
    --to=martin.agren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=hkleynhans@bloomberg.net \
    --cc=peff@peff.net \
    --cc=t.gummerer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).