Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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',

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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 > >

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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 >

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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. >

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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 --

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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"

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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.

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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,

[PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

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"