Re: [PATCH v2 1/1] fetch: allow adding a filter after initial clone.
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 28, 2020, 15:04 UTC
- Message-ID
- <xmqqsgfk3xtd.fsf@gitster.c.googlers.com>
- In-Reply-To
- <20200528025359.20931-2-delphij@google.com>
Xin Li <delphij@google.com> writes:
Show 5 quoted lines
> 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.