[PATCH 50/78] config.txt: move pager.* to a separate file

index 4e839db64c..a7b72d2722 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -379,14 +379,7 @@ include::config/notes.txt[] include::config/pack.txt[] -pager.:: - If the value is boolean, turns on or off pagination of the - output of a particular Git

[PATCH 40/59] config.txt: move pager.* to a separate file

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/config.txt | 9 + Documentation/pager-config.txt | 8 2 files changed, 9 insertions(+), 8 deletions(-) create mode 100644 Documentation/pager-config.txt diff --git a/Documentation/config.txt b/Documentation/config.txt

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Sat, Jun 02, 2018 at 06:46:31AM +0200, Duy Nguyen wrote: > > if (used_deprecated_reflog_option) { > > - warning("the '-l' alias for '--create-reflog' is > > deprecated;"); > > - warning("it will be removed in a future version of Git"); > > +

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Fri, May 25, 2018 at 4:40 AM, Jeff King wrote: > -- >8 -- > Subject: [PATCH] branch: customize "-l" warning in list mode > > People mistakenly use "git branch -l", thinking that it > triggers list mode. It doesn't, but the lack of non-option > arguments in that command does (and the "-l"

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Jeff King writes: > So I think you're proposing: > > - step 0: warn about "-l" when it actually gets used, and otherwise > continue ignoring > > - step 1: turn "-l" into "--list" > > - step 2: there is no step 2 > > ... So I > guess the right rule is to warn when we are not in

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Wednesday 30 May 2018 08:22 AM, Junio C Hamano wrote: Jeff King writes: Right, what I meant by "gentler" is that we continue to perform the same behavior as the old version, alongside the warning. It's arguable here because running "git branch -l" has _always_ been wrong. It's just wrong

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Wed, May 30, 2018 at 11:52:19AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > Right, what I meant by "gentler" is that we continue to perform the same > > behavior as the old version, alongside the warning. It's arguable here > > because running "git branch -l" has _always_ been

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Wed, May 30, 2018 at 11:48:32AM +0900, Junio C Hamano wrote: > Jeff King writes: > > >> - if (list) { > >> - warning("the '-l' option is an alias for > >> '--create-reflog' and"); > >> - warning("has no effect in list mode. This option will > >>

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Jeff King writes: > Right, what I meant by "gentler" is that we continue to perform the same > behavior as the old version, alongside the warning. It's arguable here > because running "git branch -l" has _always_ been wrong. It's just wrong > in a way that happens to do what the user wants. ;) >

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Jeff King writes: >> -if (list) { >> -warning("the '-l' option is an alias for >> '--create-reflog' and"); >> -warning("has no effect in list mode. This option will >> soon be"); >> -warning("removed and you should omit it

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Tue, May 29, 2018 at 05:20:29PM -0400, Jeff King wrote: > Thanks. There's one bit missing here, because it did not cause a textual > conflict during the rebase (but it's now dead code). Patch below (to be > squashed to the tip of jk/branch-l-1-removal). > [...] > - if

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Sat, May 26, 2018 at 11:32:35AM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > > Yup, thanks for being extra explicit. I do imagine there are quite > > a few of us who would be puzzled without this update (but with the > > previous one to unhide

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Sun, May 27, 2018 at 12:15:40AM +0530, Kaartic Sivaraam wrote: > > Hmm, actually, I suppose the true value of the warning is to help people > > doing "git branch -l foo", and it would still work there. The "more > > extreme" from your suggested patch would only affect "branch -l". > > > >

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Friday 25 May 2018 08:10 AM, Jeff King wrote: > Subject: [PATCH] branch: customize "-l" warning in list mode > > People mistakenly use "git branch -l", thinking that it > triggers list mode. It doesn't, but the lack of non-option > arguments in that command does (and the "-l" becomes a >

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Friday 25 May 2018 01:01 AM, Jeff King wrote: > On Thu, May 24, 2018 at 03:22:14PM -0400, Jeff King wrote: > > Hmm, actually, I suppose the true value of the warning is to help people > doing "git branch -l foo", and it would still work there. The "more > extreme" from your suggested patch

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Jeff King writes: >> By the way, this is one of these times when I feel that we should >> have a better multi-line message support in die/error/warning/info >> functions. Ideally, I should be able to write >> >> warning(_("the '-l' option is an alias for '--create-reflog'

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Junio C Hamano writes: > With these two patches queued on top of jk/branch-l-0-deprecation, > the follow-up patches jk/branch-l-1-removal that makes 'branch -l' > to fail and then jk/branch-l-2-reincarnation that makes 'branch -l' > a synonym to 'branch --list' needs rebasing.

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Junio C Hamano <gits...@pobox.com> writes: > Yup, thanks for being extra explicit. I do imagine there are quite > a few of us who would be puzzled without this update (but with the > previous one to unhide it from behind the pager). With these two patches queued on top o

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Fri, May 25, 2018 at 06:14:16PM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > >> - warning("the '-l' alias for '--create-reflog' is deprecated;"); > >> - warning("it will be removed in a future version of Git"); > >> + if (list) { >

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Junio C Hamano writes: >> -warning("the '-l' alias for '--create-reflog' is deprecated;"); >> -warning("it will be removed in a future version of Git"); >> +if (list) { >> +warning("the '-l' option is an alias for >>

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

e left puzzled. Yup, thanks for being extra explicit. I do imagine there are quite a few of us who would be puzzled without this update (but with the previous one to unhide it from behind the pager). > Let's make it clear that: > > 1. No, "-l" didn't do what they thought h

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Fri, May 25, 2018 at 10:55:45AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > Hmm, actually, I suppose the true value of the warning is to help people > > doing "git branch -l foo", and it would still work there. The "more > > extreme" from your suggested patch would

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Jeff King writes: > Hmm, actually, I suppose the true value of the warning is to help people > doing "git branch -l foo", and it would still work there. The "more > extreme" from your suggested patch would only affect "branch -l". > Still, I think I prefer the gentler version

[PATCH] branch: issue "-l" deprecation warning after pager starts

tler version that we get by keeping it as a warning even in the latter case. Here's the patch. It goes on top of jk/branch-l-0-deprecation (and will naturally conflict with the removal branch, but the resolution should be obvious). -- >8 -- Subject: [PATCH] branch: issue "-l" deprec

Re: [PATCH] pager: set COLUMNS to term_columns()

- * the standard output to the pager. > +* After we redirect standard output, we won't be able to use an ioctl > +* to get the terminal size. Let's grab it now, and then set $COLUMNS > +* to communicate it to any sub-processes. >

[PATCH] pager: set COLUMNS to term_columns()

ot; part which should be > fixed anyway. Heh. OK, here it is. I wondered why we didn't notice this earlier and elsewhere (like in "git -p help -a"). The answer is that git-tag is the only program that uses the column filter. Everybody else does it in-process. -- >8 -- Subject: [P

Re: [PATCH v2] git: add -P as a short option for --no-pager

Eric Sunshine writes: >> available. Provide a short option, -P, to make the option easier >> accessible. > > s/easier accessible/easier to access/ > --- or --- > s/easier accessible/more easily accessible/ > --- or --- > s/easier accessible/more accessible/ > > The patch

Re: [PATCH v2] git: add -P as a short option for --no-pager

On Thu, May 3, 2018 at 1:15 PM, Johannes Sixt <j...@kdbg.org> wrote: > It is possible to configure 'less', the pager, to use an alternate > screen to show the content, for example, by setting LESS=RS in the > environment. When it is closed in this configuration, it switches > ba

[PATCH v2] git: add -P as a short option for --no-pager

It is possible to configure 'less', the pager, to use an alternate screen to show the content, for example, by setting LESS=RS in the environment. When it is closed in this configuration, it switches back to the original screen, and all content is gone. It is not uncommon to request

Re: js/no-pager-shorthand [

Eric Sunshine <sunsh...@sunshineco.com> writes: > Although paged output is generally nice, I frequently find myself > typing --no-pager numerous times during the day, so I, for one, > welcome having a short option (and would be sad to see this patch > retracted). As with Han

Re: js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]

On Tue, May 01 2018, Johannes Schindelin wrote: > I wonder whether `-!p` would be better/feasible? In *nix shells `git -!p ...` unquoted will turn that !p into whatever command you last ran that started with a "p", in my case `git -ping 8.8.8.8`. So there's a reason that's not the idiom in any

Re: js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]

On Tue, May 1, 2018 at 10:58 AM, Johannes Sixt <j...@kdbg.org> wrote: > Am 01.05.2018 um 13:57 schrieb Johannes Schindelin: >> On Mon, 30 Apr 2018, Johannes Sixt wrote: >>> Am 30.04.2018 um 05:25 schrieb Junio C Hamano: >>>> * js/no-pager-shorthand (2018-0

Re: js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]

Am 01.05.2018 um 13:57 schrieb Johannes Schindelin: Hi Hannes, On Mon, 30 Apr 2018, Johannes Sixt wrote: Am 30.04.2018 um 05:25 schrieb Junio C Hamano: * js/no-pager-shorthand (2018-04-25) 1 commit - git: add -N as a short option for --no-pager "git --no-pager cmd" did not

Re: js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]

Hi Hannes, On Mon, 30 Apr 2018, Johannes Sixt wrote: > Am 30.04.2018 um 05:25 schrieb Junio C Hamano: > > * js/no-pager-shorthand (2018-04-25) 1 commit > > - git: add -N as a short option for --no-pager > > > > "git --no-pager cmd" did not have short

Re: [PATCH] git: add -N as a short option for --no-pager

would probably abbreviate as -x or -X. So, -P is perhaps not that bad > after all. > It might be a good choice but I don't think it's not the best choice anyway because '-P' doesn't seem to communicate 'no pager' well. > Perhaps --no-pager means also "unpaginated" (-u,

Re: [PATCH] git: add -N as a short option for --no-pager

On Thursday 26 April 2018 01:01 AM, Johannes Sixt wrote: > > Right. But I have LESS=RS because I do *not* want it to remain on screen > by default. > In that case how about updating the commit message to be more clear about it. How about, It is possible to configure 'less

js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]

Am 30.04.2018 um 05:25 schrieb Junio C Hamano: * js/no-pager-shorthand (2018-04-25) 1 commit - git: add -N as a short option for --no-pager "git --no-pager cmd" did not have short-and-sweet single letter option. Now it does. Will merge to 'next'. I consider your argume

Re: [PATCH] git: add -N as a short option for --no-pager

Am 25.04.2018 um 11:21 schrieb Phillip Wood: On 24/04/18 17:59, Johannes Sixt wrote: In modern setups, less, the pager, uses alternate screen to show the content. When it is closed, it switches back to the original screen, and all content is gone. Are you setting LESS explicitly

Re: [PATCH] git: add -N as a short option for --no-pager

n your setups? I have LESS=RS in my environment, because I do want that the alternate screen is used by the pager. Nevertheless, occasionally I want git's output to remain visible. -- Hannes

Re: [PATCH] git: add -N as a short option for --no-pager

On 24/04/18 17:59, Johannes Sixt wrote: In modern setups, less, the pager, uses alternate screen to show the content. When it is closed, it switches back to the original screen, and all content is gone. Are you setting LESS explicitly in the environment? From the git config man page: When

Re: [PATCH] git: add -N as a short option for --no-pager

Hi Hannes, On Wed, 25 Apr 2018, Johannes Sixt wrote: > Am 25.04.2018 um 02:05 schrieb Junio C Hamano: > > Johannes Sixt writes: > > > It is not uncommon to request that the output remains visible in > > > the terminal. I ran `git log` and then hit `q`, and the latest screen

Re: [PATCH] git: add -N as a short option for --no-pager

Am 25.04.2018 um 02:05 schrieb Junio C Hamano: Johannes Sixt <j...@kdbg.org> writes: It is not uncommon to request that the output remains visible in the terminal. For this, the option --no-pager can be used. But it is a bit cumbersome to type, even when command completion is available. P

Re: [PATCH] git: add -N as a short option for --no-pager

On Wed, Apr 25, 2018 at 09:05:56AM +0900, Junio C Hamano wrote: > Johannes Sixt <j...@kdbg.org> writes: > > > In modern setups, less, the pager, uses alternate screen to show > > the content. When it is closed, it switches back to the original > > s

Re: [PATCH] git: add -N as a short option for --no-pager

Johannes Sixt <j...@kdbg.org> writes: > In modern setups, less, the pager, uses alternate screen to show > the content. When it is closed, it switches back to the original > screen, and all content is gone. > > It is not uncommon to request that the output remains visi

[PATCH] git: add -N as a short option for --no-pager

In modern setups, less, the pager, uses alternate screen to show the content. When it is closed, it switches back to the original screen, and all content is gone. It is not uncommon to request that the output remains visible in the terminal. For this, the option --no-pager can be used

[PATCH 2/4] pager: refactor `pager_command_config()`

`pager_command_config()` checks for the config `pager.`. In the next commit, we will want to also look for some strings on the form `pager..foo`. Refactor the code to verify upfront that the string starts with "pager." and then check that the remainder is the empty string. This mak

[PATCH 3/4] pager: introduce `pager.*.command` and `.enable`

with the existing `pager.foo`. For example, make sure that `pager.foo=false` does not cause us to forget about a command already configured through `pager.foo.command`, so that the given pager command can be "re-activated" using `pager.foo[.enable]=true`. Where Documentation/ refers to `pager.t

[PATCH 4/4] pager: make `pager.foo.command` imply `.enable=true`

+++ b/Documentation/config.txt @@ -2470,6 +2470,8 @@ pager..command:: Specifies the pager to use for the subcommand. Whether the pager should be used is configured using `pager..enable` or `pager.=`. + Implies `pager..enable=true` unless `pager..enable` + or `pager.` have a

Re: [PATCH v2] column: show auto columns when pager is active

On Mon, Oct 23, 2017 at 02:52:46PM -0700, Jonathan Nieder wrote: > Hi, > > Kevin Daudt wrote: > > > --- a/column.c > > +++ b/column.c > > @@ -5,6 +5,7 @@ > > #include "parse-options.h" > > #include "run-command.h" > > #include "utf8.h" > > +#include "pager.c" > > Should this be pager.h? > >

Re: [PATCH v2] column: show auto columns when pager is active

Junio C Hamano wrote: > Subject: column: do not include pager.c > > Everything this file needs from the pager API (e.g. term_columns(), > pager_in_use()) is already declared in the header file it includes. > > Noticed-by: Jonathan Nieder <jrnie...@gmail.com> > Signed-o

Re: [PATCH v2] column: show auto columns when pager is active

uot; >> +#include "pager.c" > > Should this be pager.h? Ouch. And I was not paying enough attention. Thanks, I'll queue this on top. -- >8 -- Subject: column: do not include pager.c Everything this file needs from the pager API (e.g. term_columns(), pager_in_use()) is

Re: [PATCH v2] column: show auto columns when pager is active

Hi, Kevin Daudt wrote: > --- a/column.c > +++ b/column.c > @@ -5,6 +5,7 @@ > #include "parse-options.h" > #include "run-command.h" > #include "utf8.h" > +#include "pager.c" Should this be pager.h? Thanks, Jonathan

Re: [PATCH v2] column: show auto columns when pager is active

Kevin Daudt <m...@ikke.info> writes: > When columns are set to automatic for git tag and the output is > paginated by git, the output is a single column instead of multiple > columns. > > Standard behaviour in git is to honor auto values when the pager is > active, w

[PATCH v2] column: show auto columns when pager is active

When columns are set to automatic for git tag and the output is paginated by git, the output is a single column instead of multiple columns. Standard behaviour in git is to honor auto values when the pager is active, which happens for example with commands like git log showing colors when being

Re: [RFC] column: show auto columns when pager is active

On Wed, Oct 11, 2017 at 06:54:04AM +0200, Kevin Daudt wrote: > > > Yeah, I didn't think of that with respect to the pager. This is a > > > regression in v2.14.2, I think. > > > > Yes. > > Though 2.14.2 enabled the pager by default, even before that when

Re: [PATCH] column: show auto columns when pager is active

`git tag` with column.ui=auto and it would do the columns-thing. But with ff1e72483, the behavior changed. To add insult to injury, it might be non-obvious that the pager is running, since with just a few tags, the pager simply exits silently. So debugging this could probably be quite frustrating. Martin

Re: [PATCH] column: show auto columns when pager is active

t to auto. Also check > > if the pager is active. > > Maybe you could say something about the difficulties of writing a test > for `git column` proper. Something like this perhaps: > > Adding a test for git column is possible but requires some care to > work around a race

Re: [PATCH] column: show auto columns when pager is active

On 11 October 2017 at 19:23, Kevin Daudt <m...@ikke.info> wrote: > finalize_colopts in column.c only checks whether the output is a TTY to > determine if columns should be enabled with columns set to auto. Also check > if the pager is active. Maybe you could say something about t

[PATCH] column: show auto columns when pager is active

When columns are set to automatic for git tag and the output is paginated by git, the output is a single column instead of multiple columns. Standard behaviour in git is to honor auto values when the pager is active, which happens for example with commands like git log showing colors when being

Re: [RFC] column: show auto columns when pager is active

>> > Since ff1e72483 (tag: change default of `pager.tag` to "on", > >> > 2017-08-02), the pager has been enabled by default, exposing this > >> > problem to more people. > >> > >> Oh. :( I didn't know about "column" to be honest

Re: [RFC] column: show auto columns when pager is active

o > > read the input before the stdin terminal is closed. > > > > I'm not sure of an easy way to fix test-terminal, but we could work > > around it like this (which also uses "-p" to actually invoke the pager, > > and uses a pager that makes it clear when it's bei

Re: [RFC] column: show auto columns when pager is active

an easy way to fix test-terminal, but we could work > around it like this (which also uses "-p" to actually invoke the pager, > and uses a pager that makes it clear when it's being run): > > diff --git a/t/t9002-column.sh b/t/t9002-column.sh > index 9441145bf0..d322c3b745

Re: [RFC] column: show auto columns when pager is active

On 10 October 2017 at 16:01, Jeff King <p...@peff.net> wrote: > On Tue, Oct 10, 2017 at 12:30:49PM +0200, Martin Ågren wrote: >> On 9 October 2017 at 23:45, Kevin Daudt <m...@ikke.info> wrote: >> > Since ff1e72483 (tag: change default of `pager.tag` to "on&quo

Re: [RFC] column: show auto columns when pager is active

read the input before the stdin terminal is closed. I'm not sure of an easy way to fix test-terminal, but we could work around it like this (which also uses "-p" to actually invoke the pager, and uses a pager that makes it clear when it's being run): diff --git a/t/t9002-column.sh b/t/t

Re: [RFC] column: show auto columns when pager is active

On Mon, Oct 09, 2017 at 11:45:43PM +0200, Kevin Daudt wrote: > +test_expect_success TTY '20 columns, mode auto, pager' ' > + cat >expected <<\EOF && > +oneseven > +twoeight > +three nine > +four ten > +five eleven > +six > +EOF > +

Re: [RFC] column: show auto columns when pager is active

; columns. > > > > Standard behaviour in git is to honor auto values when the pager is > > active, which happens for example with commands like git log showing > > colors when being paged. > > > > Since ff1e72483 (tag: change default of `pager.tag` to "o

Re: [RFC] column: show auto columns when pager is active

On 9 October 2017 at 23:45, Kevin Daudt <m...@ikke.info> wrote: > When columns are set to automatic for git tag and the output is > paginated by git, the output is a single column instead of multiple > columns. > > Standard behaviour in git is to honor auto values when the pag

Re: [RFC] column: show auto columns when pager is active

On Mon, Oct 9, 2017 at 5:45 PM, Kevin Daudt <m...@ikke.info> wrote: > When columns are set to automatic for git tag and the output is > paginated by git, the output is a single column instead of multiple > columns. > > Standard behaviour in git is to honor auto values when

[RFC] column: show auto columns when pager is active

When columns are set to automatic for git tag and the output is paginated by git, the output is a single column instead of multiple columns. Standard behaviour in git is to honor auto values when the pager is active, which happens for example with commands like git log showing colors when being

[PATCH v3 7/7] git.c: ignore pager.* when launching builtin as dashed external

;, 2016-01-26). Shortly before we launch a dashed external, and unless we have already found out whether we should use a pager, we check `pager.foo`. This was added in commit 92058e4d ("support pager.* for external commands", 2011-08-18). If the dashed external is a builtin, this does not

Re: [PATCH v2 10/10] git.c: ignore pager.* when launching builtin as dashed external

On 31 July 2017 at 05:45, Jeff King wrote: > On Mon, Jul 17, 2017 at 10:10:52PM +0200, Martin Ågren wrote: > >> One could address this in run_argv(), by making the second call to >> execv_dashed_external() conditional on "!is_builtin()" whereas a builtin >> would be started as "git

Re: [PATCH v2 10/10] git.c: ignore pager.* when launching builtin as dashed external

s > added in commit 441981bc ("git: simplify environment save/restore > logic", 2016-01-26). > > Shortly before we launch a dashed external, and unless we have already > found out whether we should use a pager, we check `pager.foo`. This was > added in commit 92058e4d (&

[PATCH v2 10/10] git.c: ignore pager.* when launching builtin as dashed external

;, 2016-01-26). Shortly before we launch a dashed external, and unless we have already found out whether we should use a pager, we check `pager.foo`. This was added in commit 92058e4d ("support pager.* for external commands", 2011-08-18). If the dashed external is a builtin, this does not

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

On 11 July 2017 at 00:42, Junio C Hamano <gits...@pobox.com> wrote: > Martin Ågren <martin.ag...@gmail.com> writes: >> I am not moving all builtins to handling the pager on their own, >> but instead introduce a flag IGNORE_PAGER_CONFIG and use it only >> with th

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

Jeff King writes: >> I see you CC'ed Peff who's passionate in this area, so these patches >> are in good hands already ;-) I briefly skimmed your patches myself, >> and did not spot anything glaringly wrong. > > Heh, I don't think of "paging tag output" as one of my passions, but

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

n that makes that approach less > clean. You have convinced me that I will instead try to teach git tag > to be more clever about when to use the pager, at least to see what > that looks like. Thanks. I was the original proponent of "pager.tag.list", and only after reading your s

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

terminal. >> A user who makes use of `git tag -a` and `git tag -l` will probably >> choose not to configure `pager.tag` or to set it to "no", so that `git >> tag -a` will actually work, at the cost of not getting the pager with >> `git tag -l`. > > Right

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

On Mon, Jul 10, 2017 at 03:42:14PM -0700, Junio C Hamano wrote: > > A review would be much appreciated. Comments on the way I > > structured the series would be just as welcome as ones on the > > final result. > > I see you CC'ed Peff who's passionate in this area, so these patches > are in good

Re: [PATCH 7/7] tag: make git tag -l use pager by default

On Mon, Jul 10, 2017 at 11:55:20PM +0200, Martin Ågren wrote: > The previous patch introduced `pager.tag.list`. Its default was to use > the value of `pager.tag` or, if that was also not set, to fall back to > "off". > > Change that fallback value to "on". Let the default value for > `pager.tag`

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

l probably > choose not to configure `pager.tag` or to set it to "no", so that `git > tag -a` will actually work, at the cost of not getting the pager with > `git tag -l`. Right, I think we are all agreed that "pager.tag" as it is now is essentially worthless. If I u

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

not to configure `pager.tag` or to set it to > "no", so that `git tag -a` will actually work, at the cost of not > getting the pager with `git tag -l`. > > In the discussion at [1], it was brought up that 1) the individual > builtins should be in charge of setting up the

[PATCH 7/7] tag: make git tag -l use pager by default

xt index 6ad5811a2..fbdfb3f59 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -103,7 +103,7 @@ as `--contains` is provided. See the documentation for each of those options for details. + When determining whether to use a pager, `pager.tag.list` is considered -be

[PATCH 0/7] tag: more fine-grained pager-configuration

t;, so that `git tag -a` will actually work, at the cost of not getting the pager with `git tag -l`. In the discussion at [1], it was brought up that 1) the individual builtins should be in charge of setting up the paging (as opposed to git.c which has no knowledge about what the command is about to do) and

Re: git diff sometimes brings up buggy pager

Any chance you can tell us what repo this happens on? + git version, OS, and what the triggering diff invocation is. On Thu, Jun 15, 2017 at 12:19 PM, Matthew Groth wrote: > When I do `git diff` sometimes I get this: > > > ...skipping... > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ >

git diff sometimes brings up buggy pager

When I do `git diff` sometimes I get this: ...skipping... ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ...skipping... ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ...skipping... ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ it goes on like this for about 10 times the length. Looks like this happens

Re: [PATCH 0/3] fix ^C killing pager when running alias

in general. >>> > >>> > We do apply some special behavior for certain cases like we do for the >>> > pager. And now the case with aliases is another special situation. The >>> > parent git process only delegates to the child, and as such it is >>>

Re: [PATCH 0/3] fix ^C killing pager when running alias

e of a (deadly) signal to have the >> > process go away. There may be programs that know it better, like less, but >> > git should not attempt to know better in general. >> > >> > We do apply some special behavior for certain cases like we do for the >> > pager. And

[PATCH 0/3] fix ^C killing pager when running alias

better, like less, but > > git should not attempt to know better in general. > > > > We do apply some special behavior for certain cases like we do for the > > pager. And now the case with aliases is another special situation. The > > parent git process only dele

Re: Regression: Ctrl-c from the pager in an alias exits it

processes when a signal > was received. After all, it is the purpose of a (deadly) signal to have the > process go away. There may be programs that know it better, like less, but > git should not attempt to know better in general. > > We do apply some special behavior for certain cases like

Re: Regression: Ctrl-c from the pager in an alias exits it

s the purpose of a (deadly) signal to have the process go away. There may be programs that know it better, like less, but git should not attempt to know better in general. We do apply some special behavior for certain cases like we do for the pager. And now the case with aliases is another special

Re: Regression: Ctrl-c from the pager in an alias exits it

On Fri, Jan 06, 2017 at 03:39:59PM +0100, Johannes Sixt wrote: > > diff --git a/run-command.c b/run-command.c > > index ca905a9e80..db47c429b7 100644 > > --- a/run-command.c > > +++ b/run-command.c > > @@ -29,6 +29,8 @@ static int installed_child_cleanup_handler; > > > > static void

Re: Regression: Ctrl-c from the pager in an alias exits it

Am 06.01.2017 um 08:32 schrieb Jeff King: On Fri, Jan 06, 2017 at 02:26:02AM -0500, Jeff King wrote: You'll notice that it actually calls wait() on the pager. That's due to a3da882120 (pager: do wait_for_pager on signal death, 2009-01-22), which IIRC was addressing a very similar problem. We

Re: Regression: Ctrl-c from the pager in an alias exits it

On Fri, Jan 06, 2017 at 02:32:25 -0500, Jeff King wrote: > And here's a patch to do that. It seems to work. Nice, thanks! This works very well for me too. -- Trygve Aaberge

Re: Regression: Ctrl-c from the pager in an alias exits it

On Fri, Jan 06, 2017 at 02:26:02AM -0500, Jeff King wrote: > You'll notice that it actually calls wait() on the pager. That's due to > a3da882120 (pager: do wait_for_pager on signal death, 2009-01-22), which > IIRC was addressing a very similar problem. We want to stop feeding the > p

Re: Regression: Ctrl-c from the pager in an alias exits it

On Fri, Jan 06, 2017 at 01:47:52AM -0500, Jeff King wrote: > > > To reproduce, create e.g. the alias `l = log` and run `git l`. Then press > > > Ctrl-c. The expected behavior is that nothing happens. The actual > > > behavior is > > > that the pager e

Re: Regression: Ctrl-c from the pager in an alias exits it

On Fri, Jan 06, 2017 at 01:40:32AM -0500, Jeff King wrote: > On Thu, Jan 05, 2017 at 03:25:29PM +0100, Trygve Aaberge wrote: > > > I'm experiencing an issue when using aliases for commands that open the > > pager. > > When I press Ctrl-c from the pager, it exits. Thi

Re: Regression: Ctrl-c from the pager in an alias exits it

On Thu, Jan 05, 2017 at 03:25:29PM +0100, Trygve Aaberge wrote: > I'm experiencing an issue when using aliases for commands that open the pager. > When I press Ctrl-c from the pager, it exits. This does not happen when I > don't use an alias and did not happen before. It causes problem

Regression: Ctrl-c from the pager in an alias exits it

I'm experiencing an issue when using aliases for commands that open the pager. When I press Ctrl-c from the pager, it exits. This does not happen when I don't use an alias and did not happen before. It causes problems because Ctrl-c is also used for other things, such as canceling a search

Re: Bug: pager. doesn't work well with editors

On Thu, Sep 22, 2016 at 10:19:32AM -0700, Junio C Hamano wrote: > The level at which configurability happens might be one issue > (i.e. you may want different pager for two operating modes for the > same command, hence your need to use "tag.list" not just "tag")

Re: Bug: pager. doesn't work well with editors

> happening at the wrong level. The level at which configurability happens might be one issue (i.e. you may want different pager for two operating modes for the same command, hence your need to use "tag.list" not just "tag"), but I think another issue is that it conflates

  1   2   3   >