On 11/13/2018 10:24 PM, Junio C Hamano wrote:
Jonathan Nieder <jrnieder@xxxxxxxxx> 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.
