Xin Li <delphij@xxxxxxxxxx> writes: > Instead of bailing out immediately when no promisor is available, make > the code check more specific issue (extension became special in > repository version 1, while it can have any value in version 0, so > upgrade should not happen if the repository have an unsupported > configuration that would render it invalid if we upgraded). It probably has to be a lot stronger than that. In version 0, extension did not have any meaning, so an existing repository can safely have "[extension] worktreeConfig=~/hello" as long as it is version 0 and nobody would bitch about extension.worktreeConfig not being a boolean; worse yet, "[extension] worktreeConfig=true" in version 0 repository did not make its secondary worktrees to have separate configuration, but if we upgrade to version 1 merely because the version of Git knows what extension.worktreeConfig means, we broke the repository and its worktrees. It would be safe to upgrade version 0 repository when there is *no* existing configuration variable in the "extension" section, but "the repository have an unsupported configuration" is not a useful or safe criteria to decide if we should refrain from upgrading, I would think.
