On Thu, Mar 07, 2019 at 09:50:57AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Mostly I was just surprised by the new behavior. Perhaps the right
> > solution is not a patch to the code, but to the documentation. Something
> > like:
>
> Let me forge your sign-off and commit this to p
Jeff King writes:
> Mostly I was just surprised by the new behavior. Perhaps the right
> solution is not a patch to the code, but to the documentation. Something
> like:
Let me forge your sign-off and commit this to prevent us from
forgetting.
Thanks, all.
-- >8 --
From: Jeff King
Date: Mon,
Hi Johannes,
On Sat, Mar 02, 2019 at 09:25:28PM +0100, Johannes Schindelin wrote:
> Hi Taylor,
>
> On Fri, 1 Mar 2019, Taylor Blau wrote:
>
> > [ ... ]
>
> This should do the right thing if you write
>
> printf "" >expect
>
> instead?
>
> Ciao,
> Dscho
>
> > + printf "\\033[31m" >expect &&
On Tue, Mar 05, 2019 at 02:57:32PM +0900, Junio C Hamano wrote:
> Yup, that would be a very sensible first step, regardless of what
> the next step is.
>
> After that, choices are
>
> (1) we'd introduce new inconsistency among --type= by
> matching what --type=color does to what --get-color d
Hi Peff,
On Sun, 3 Mar 2019, Jeff King wrote:
> On Sat, Mar 02, 2019 at 09:25:28PM +0100, Johannes Schindelin wrote:
>
> > > This bug has survived because there was never a test that would have
> > > caught it. The old test used 'test_decode_color', which checks that its
> > > input begins with
Jeff King writes:
> I do wonder, though, if we're digging ourselves a hole with the
> inconsistency between different --types that will bite us later. Given
> that it's not that hard to chomp the output (and as you noted, the shell
> does it fairly transparently), and given that the caller has to
On Mon, Mar 04, 2019 at 02:05:40PM +0900, Junio C Hamano wrote:
> >> With respect to backwards compatibility, my thinking on the matter was
> >> basically:
> >>
> >> 1. Since --type=color was supposed to be a drop-in replacement for
> >> --get-color, it's a bug that they don't behave the sa
Junio C Hamano writes:
> Jeff King writes:
>
>> I'm not sure I agree. Colors have always been special, and
>> "--type=color" was advertised as a replacement for "--get-color". And
>> "--get-color" never output the newline.
>
> OK, that part of the motivation I completely missed. If end-users
>
Jeff King writes:
> I'm not sure I agree. Colors have always been special, and
> "--type=color" was advertised as a replacement for "--get-color". And
> "--get-color" never output the newline.
OK, that part of the motivation I completely missed. If end-users
and scripters are happy with the beh
On Sun, Mar 03, 2019 at 10:18:11AM +0900, Junio C Hamano wrote:
> An interesting aspect of the above is that this is *NOT* limited to
> colors. Regardless of the type you are reading, be it an int or a
> bool, VAR=$(git config ...) will strip the trailing LF, and existing
> scripts people have do
On Sat, Mar 02, 2019 at 09:25:28PM +0100, Johannes Schindelin wrote:
> > This bug has survived because there was never a test that would have
> > caught it. The old test used 'test_decode_color', which checks that its
> > input begins with a color, but stops parsing once it has parsed a single
> >
Taylor Blau writes:
> Invocations of 'git config ' print a trailing newline after
> writing the value assigned to the given configuration variable.
>
> This has an unexpected interaction with 63e2a0f8e9 (builtin/config:
> introduce `color` type specifier, 2018-04-09), which causes a newline to
>
Hi Taylor,
On Fri, 1 Mar 2019, Taylor Blau wrote:
> Invocations of 'git config ' print a trailing newline after
> writing the value assigned to the given configuration variable.
>
> This has an unexpected interaction with 63e2a0f8e9 (builtin/config:
> introduce `color` type specifier, 2018-04-09
On Fri, Mar 1, 2019 at 7:41 PM Taylor Blau wrote:
> [...]
> In this case, printing a terminating newline is not desirable. Callers
> may want to print out such a configuration variable in a sub-shell in
> order to color something else, in which case they certainly don't want a
> newline.
It's ext
Invocations of 'git config ' print a trailing newline after
writing the value assigned to the given configuration variable.
This has an unexpected interaction with 63e2a0f8e9 (builtin/config:
introduce `color` type specifier, 2018-04-09), which causes a newline to
be printed after a color's ANSI e
15 matches
Mail list logo
