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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Ah, right, I forgot about that one while I was putting it together. So
many alternatives floating around.

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

To be honest, I'm not actually very worried. I think missing a
post-revert adjustment is the main risk, but my general sense is that
there hasn't been a lot going on with color fixes outside of my recent
work. Famous last words and all that, I'm sure. :)

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

After pondering over it, I have a slight preference for that, too. But
I'm also happy to hear more input.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux