Re: "bad revision" fetch error when fetching missing objects from partial clones

From: Derrick Stolee <stolee@gmail.com>
Date: May 18, 2021, 14:04 UTC
Message-ID: <d22edf0d-1d37-ed4a-6b61-0ee56b359aa5@gmail.com>
In-Reply-To: <1bedacfb-2b03-85e6-71d6-0f64fab68bbc@gmail.com>

On 5/18/2021 6:14 AM, Bagas Sanjaya wrote:

Show 24 quoted lines

> On 18/05/21 15.11, Jeff King wrote:
>> In practice I think it's an unlikely failure mode for a server you
>> partial-cloned from to turn off filters, so it's probably not that
>> important. I hit it because a test script used test_config to enable
>> them, and then the follow-on test I added to run git-fetch got quite
>> confused. A more likely scenario is that you might see it a
>> misconfigured load-balanced pool of servers.
>>
>> I do wonder how hitting a third-party server should work, though. E.g.,
>> I partial clone from A, and then ask B to fetch some related history
>> built on top. Do I tell B that I'm a partial clone and might be missing
>> some objects? Or do I behave as normal, and expect to fault in objects
>> that it assumes I have (e.g., a delta base)? And if the latter, does
>> that work (if it does, then why doesn't the same logic kick in for this
>> fetch?).
>>
> 
> My server is running Gitea (compiled from main branch [1]). The server
> itself runs Git 2.31.1. I can also reproduce the issue using Jeff's
> test case [2] without Gitea. So this is not Gitea's issue, this is Git's
> issue.
> 
> Even my server setup is just application server + separate database
> server and not load-balanced pool ones.

I think the "third party" thing is mostly about if we have forks hosted in different places. Imagine that git/git is hosted on GitHub with partial clone enabled, but git-for-windows/git was hosted on Azure Repos, which doesn't have partial clone.

What happens when we partial clone git/git from GitHub, but then add git-for-windows/git as a remote and fetch from it?

This is a separate discussion. I think it really points out the issues that arise because partial clone makes the remote a more critical resource. This removes some decentralization from Git, as requested by the user. These concerns about the remote changing the availability of filters or about other remotes hosted elsewhere are unlikely to come up in a centralized workflow (i.e. a set of users working against a common remote without forks).

Thanks, -Stolee