Re: [PATCH 3/3] index: do not warn about unrecognized extensions

From: Ben Peart <peartben@gmail.com>
Date: Nov 14, 2018, 18:19 UTC
Message-ID: <70f48153-fedf-4b82-780b-eca08981a8eb@gmail.com>
In-Reply-To: <xmqqh8gkqr2l.fsf@gitster-ct.c.googlers.com>

On 11/13/2018 10:24 PM, Junio C Hamano wrote:

Show 18 quoted lines

> Jonathan Nieder <jrnieder@gmail.com> 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

Show 14 quoted lines

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