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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 14, 2017, 03:01 UTC
Message-ID: <xmqqshemtoth.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171013130638.dgc6kawy5mvrbasz@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

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

Yes, I think that is the approach I was pushing initially with the jc/ref-filter-colors-fix topic that was later retracted; the result of your 4-patch series more or less matches that one, modulo that I didn't treat for-each-ref as a plumbing. I do share the worry that it is hard to make sure that these post-revert adjustment caught everything; after all, that was a major part of the reason why my earlier attempt was retracted. I still think this is the _right_ direction to go in, even though it is harder to get right.

Show 6 quoted lines

> Post-release, we would either:
> ...
> But we could punt on that part until after the release. The only thing
> we'd need to decide on now is that first set of reversions. What I
> really _don't_ want to do is ship v2.15 with "always works like auto"
> and then flip that back in v2.16.

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 approaches would probably work well in practice, I have preference for this "harder but right" approach, so I'd want to see different views discussed on the list before we decide.

Thanks.