Martin Ågren [off-list ref] writes:
quoted
IOW, you question "if we go a few releases without any major issues"
part? I tend to agree that for a large change like this, a few
releases may not be sufficiently long time for a feature that is
marked as experimental in big flashing red letters to get exercised
enough to get major issues noticed.
Yeah, thanks for summarizing what I failed to express using so many
words.
I'm fully open to the idea that some people want to leave SHA-1 behind
and that they can do it today, in some "local" sense. If those people
are fully aware that they are guinea pigs, it might actually be ok for
us to subject them to a few rounds of "oops, Git v2.32.0 produces data
that v2.34.0 and later will barf on". Or at least it would be on our
table whether we wanted to be that cavalier.
Once SHA-256 repos as such are no longer experimental, I fear that we
can only buy ourselves that leeway by introducing fiftyeleven different
config flags for "please produce auxiliary files X even if you don't
actually use them", "please do use X, and I'm fully expecting to trip on
them if you decide to tweak them in backwards-incompatible ways", and so
on. The alternative to buying such leeway might be to establish, pretty
early on, a respectable set of things we support "for compatibility
reasons".
OK, so can we resolve this one way or the other and move on?
For now, I'd vote for applying this warning patch, but with or
without such warning, it is more important to iron out those details
we fear might have to change.
Thanks.