Hi, On Tue, 14 Jul 2020, Derrick Stolee wrote: > On 7/14/2020 11:27 AM, Junio C Hamano wrote: > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > >>> If you don't mind, I was already going to squash Junio's commit into > >>> mine (almost completely replacing mine) but I could add a small > >>> commit on top that provides the following improvement to the error > >>> message: > >> > >> I don't mind at all. I'd just like to know that v2.28.0 avoids confusing > >> users in the same was as v2.28.0-rc0 confused me. > > > > In a nearby thread, Jonathan Nieder raised an interesting approach > > to avoid confusing users, which I think (if I am reading him > > correctly) makes sense (cf. <20200714040616.GA2208896@xxxxxxxxxx>) > > > > What if we accept the extensions the code before the topic in > > question that was merged in -rc0 introduced the "confusion" accepts > > even in v0? If we see extensions other than those handpicked and > > grandfathered ones (which are presumably the ones we add later and > > support in v1 and later repository versions) in a v0 repository, we > > keep ignoring. Also we'd loosen the overly strict code that > > prevents upgrading from v0 to v1 in the presence of any extensions > > in -rc0, so that the grandfathered ones will not prevent the > > upgrading. > > > > The original reasoning behind the strict check was because the users > > could have used extensions.frotz for their own use with their own > > meaning, trusting that Git would simply ignore it, and an upgrade to > > later version in which Git uses extensions.frotz for a purpose that > > is unrelated to the reason why these users used would just break the > > repository. > > > > But the ones that were (accidentally) honored in v0 couldn't have > > been used by the users for the purposes other than how Git would use > > them anyway, so there is no point to make them prevent the upgrade > > of the repository version from v0 to v1. > > > > At least, that is how I understood the world would look like in > > Jonathan's "different endgame". > > > > What do you three (Dscho, Derrick and Jonathan) think? > > If "v0" includes "core.repositoryFormatVersion is unset" then I > would consider this to be a way to avoid all user pain, which is > positive. I concur. > I'd be happy to test and review a patch that accomplishes this > goal. Wouldn't that just be a matter of extending your patch to re-set `has_unhandled_extensions` also for `preciousObjects` and `partialClone`? Ciao, Dscho > > CC'ing Ed Thomson because this extension stuff affects other tools, > like libgit2. > > Thanks, > -Stolee > >
