Jeff King writes:
>> It was a bit more painful than necessary to make sure I have
>> something that can be merged for 2.14.x maintenance track, but I
>> think the topic is now in a reasonable shape, and I've merged it to
>> 'next'. On the first-parent chain from 'master' to 'pu',
On Mon, Oct 16, 2017 at 11:51:01PM -0700, Jonathan Nieder wrote:
> > OK, so it seems we both have slight preference for the "peel back"
> > approach. Adding Jonathan to Cc:
>
> Which approach is "harder but right" / "peel back"?
"peel back" is reverting back to the pre-v2.14.2 state (Junio has
On Tue, Oct 17, 2017 at 03:26:25PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Jeff King writes:
> >
> >> After pondering over it, I have a slight preference for that, too. But
> >> I'm also happy to hear more input.
> >
> > OK, so it seems we
Hi,
Junio C Hamano wrote:
> Jeff King writes:
>> On Sat, Oct 14, 2017 at 12:01:46PM +0900, Junio C Hamano wrote:
>>> True. Let's see what others think. I know Jonathan is running
>>> the fork at $work with "downgrade always to auto" patches, and while
>>> I think both
Junio C Hamano writes:
> Jeff King writes:
>
>> After pondering over it, I have a slight preference for that, too. But
>> I'm also happy to hear more input.
>
> OK, so it seems we both have slight preference for the "peel back"
> approach. Adding Jonathan to
Jeff King writes:
> On Sat, Oct 14, 2017 at 12:01:46PM +0900, Junio C Hamano wrote:
>
>> > That takes us back to the pre-regression state. The ancient bug from
>> > 4c7f1819 still exists, but that would be OK for v2.15. We'd probably
>> > want to bump the -rc cycle a bit to give
On Sat, Oct 14, 2017 at 12:01:46PM +0900, Junio C Hamano wrote:
> > That takes us back to the pre-regression state. The ancient bug from
> > 4c7f1819 still exists, but that would be OK for v2.15. We'd probably
> > want to bump the -rc cycle a bit to give more confidence that (2) caught
> >
Jeff King writes:
> All of the regressions people have actually _noticed_ stem from my
> 136c8c8b8f in v2.14.2. So I think it is a viable option to try to go
> back to the pre-v2.14.2 state. I.e.:
> ...
> That takes us back to the pre-regression state. The ancient bug from
>
On Fri, Oct 13, 2017 at 12:37:57PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > OK. For the record, I'm not against scrapping this whole thing and
> > trying to rollback to your "plumbing never looks at color.ui" proposal.
> > It's quite late in the -rc cycle to do
Jeff King writes:
> OK. For the record, I'm not against scrapping this whole thing and
> trying to rollback to your "plumbing never looks at color.ui" proposal.
> It's quite late in the -rc cycle to do that, but there's nothing that
> says we can't bump the release date if that's
On Fri, Oct 13, 2017 at 09:09:09AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... Also
> > as an aside, I think this patch means that:
> >
> > git -c color.ui=always add -p
> >
> > is broken (as would a hypothetical "git --default-color=always add -p").
> > That's
Jeff King writes:
> ... Also
> as an aside, I think this patch means that:
>
> git -c color.ui=always add -p
>
> is broken (as would a hypothetical "git --default-color=always add -p").
> That's sufficiently insane that I'm not sure we should care about it.
Do you mean that
On Thu, Oct 12, 2017 at 09:06:49AM -0400, Jeff King wrote:
> > -- >8 --
> > From: Jonathan Nieder
> > Subject: color: document that "git -c color.*=always" is a bit special
> > Date: Wed, 11 Oct 2017 21:47:24 -0700
>
> This looks reasonable to me to ship in v2.15. I assume
On Thu, Oct 12, 2017 at 03:58:18PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > We need to be able to answer "why does '-c color.ui=always' work
> > only from the command line?", but I doubt we want to actively
> > encourage the use of it, though, so I dunno.
>
On Thu, Oct 12, 2017 at 11:10:06AM +0900, Junio C Hamano wrote:
> From: Jeff King
>
> An earlier patch downgraded "always" that comes via the ui.color
> configuration variable to "auto", in order to work around an
> unfortunate regression to "git add -i".
>
> That "fix" however
Junio C Hamano writes:
> We need to be able to answer "why does '-c color.ui=always' work
> only from the command line?", but I doubt we want to actively
> encourage the use of it, though, so I dunno.
For today's pushout, I've queued this as [PATCH 3/2]
Thanks..
-- >8 --
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> Should we document this special case treatment of color.* in -c
>>> somewhere? E.g.
>>
>> Perhaps, although I'd save that until we actually add the new option
>> to "git"
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Should we document this special case treatment of color.* in -c
>> somewhere? E.g.
>
> Perhaps, although I'd save that until we actually add the new option
> to "git" potty, which hasn't happened yet, if I were thinking
Jonathan Nieder writes:
> Should we document this special case treatment of color.* in -c
> somewhere? E.g.
Perhaps, although I'd save that until we actually add the new option
to "git" potty, which hasn't happened yet, if I were thinking about
adding some text like that.
Junio C Hamano wrote:
[...]
> --- a/color.c
> +++ b/color.c
> @@ -307,8 +307,21 @@ int git_config_colorbool(const char *var, const char
> *value)
> if (value) {
> if (!strcasecmp(value, "never"))
> return 0;
> - if (!strcasecmp(value,
From: Jeff King
An earlier patch downgraded "always" that comes via the ui.color
configuration variable to "auto", in order to work around an
unfortunate regression to "git add -i".
That "fix" however regressed other third-party tools that depend on
"git -c color.ui=always cmd"
21 matches
Mail list logo