Hi, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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 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. > > 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"? I agree with the goal of making color.ui=always a synonym for auto in file-based config. Peff found some problems with the warning patch (scripted commands produce too many warnings), which are not an issue for $dayjob but may be for upstream, so I see the value of holding off on the warning for now. I'm also fine with "revert the proximate cause of the latest complaints" as a stepping stone toward making color.ui=always a synonym for auto in file-based config in a later release. Another issue is diff-files paying attention to this configuration. If I'm reading Documentation/config.txt correctly, that was simply a bug. diff-files and diff-index are never supposed to use color, regardless of configuration. I'm fine with "revert the proximate cause of the latest complaints" as a stepping stone toward fixing that, too. :) Sorry I don't have more detailed advice. I was planning to look more closely at how these features evolved over time and haven't had enough time for it yet. Jonathan
