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'd be happy to test and review a patch that accomplishes this goal. CC'ing Ed Thomson because this extension stuff affects other tools, like libgit2. Thanks, -Stolee
