From: Ben Peart Date: Wed, 14 Nov 2018 18:19:31 GMT Subject: Re: [PATCH 3/3] index: do not warn about unrecognized extensions Message-ID: <70f48153-fedf-4b82-780b-eca08981a8eb@gmail.com> In-Reply-To: On 11/13/2018 10:24 PM, Junio C Hamano wrote: > Jonathan Nieder writes: > >> We cannot change the past, but for index extensions of the future, >> there is a straightforward improvement: silence that message except >> when tracing. This way, the message is still available when >> debugging, but in everyday use it does not show up so (once most Git >> users have this patch) we can turn on new optional extensions right >> away without alarming people. > > That argument ignores the "let the users know they are using a stale > version when they did use (either by accident or deliberately) a > more recent one" value, though. > > Even if we consider that this is only for debugging, I am not sure > if tracing is the right place to add. As long as the "optional > extensions can be ignored without affecting the correctness" rule > holds, there is nothing gained by letting these messages shown for > debugging purposes Having recently written a couple of patches that utilize an optional extension - I actually found the warning to be a helpful debugging tool and would like to see them enabled via tracing. It would also be helpful to see the opposite - I'm looking for an optional extension but it is missing. The most common scenario was when I'd be testing my changes in different repos and forget that I needed to force an updated index to be written that contained the extension I was trying to test. The "silently ignore the optional extension" behavior is good for end users but as a developer, I'd like to be able to have it yell at me via tracing. :-) IMHO - if an end user has to turn on tracing, I view that as a failure on our part. No end user should have to understand the inner workings of git to be able to use it effectively. and if there is such a bug (e.g. we introduced > an optional extension but the code that wrote an index with an > optional extension wrote the non-optional part in such a way that it > cannot be correctly handled without the extension that is supposed > to be optional) we'd probably want to let users notice without > having to explicitly go into a debugging session. If Googling for > "ignoring FNCY ext" gives "discard your index with 'reset HEAD', > because an index file with FNCY ext cannot be read without > understanding it", that may prevent damages from happening in the > first place. On the other hand, hiding it behind tracing would mean > the user first need to exprience an unknown breakage first and then > has to enable tracing among other 47 different things to diagnose > and drill down to the root cause. > >