On Sun, Apr 11 2021, Ævar Arnfjörð Bjarmason wrote: > On Sun, Apr 11 2021, Junio C Hamano wrote: > >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> >>> So let's just remove it instead of fixing the bug, clearly nobody's >>> cared enough to complain. >> >> Hmph, is that a safe assumption? They may have just assumed that >> you did not break it and kept using plaintext without knowing? If >> we do not give a warning when sending over an unencrypted channel in >> red flashing letters, that is more likely explanation than nobody >> caring that we saw no breakage reports, no? > > Maybe, I think in either case this patch series makes senes. We were > already 11 years into a stated deprecation period of that variable, now > it's 13. > > If we're going to e.g. emit some notice about it I think the parsing > simplification this series gives us makes sense, we can always add a > trivial patch on top to make it die if it sees the old variable. > > I don't think that's needed, do you? Junio: *Poke*. Was going thorugh my outstanding patches, I still think it makes sense to just pick this up. Especially with the related discussion later about how common in-the-wild service providers would just not support AUTH non-encrypted, so in practice I think it's even less likely that anyone saw silent breakage as a result of this already-deprecated variable being ignored.