JP Sugarbroad <jpsugar@xxxxxxxxxx> writes: > So I'm trying to make cloning the rust repo a little easier, and I > noticed there's a new feature to `git submodule update --depth=1` -- > but it doesn't work for this, even though it could. > > Reason is that fetch-pack will only fetch by sha1 if the remote > specifies allow_tip/unreachable_sha1, even if the sha1 specified > matches an advertised ref. If a project wants its users to do the 'update --depth=1' thing, it should allow fetching not just from the tip but also reachable. The commit from the submodule that is bound to the superproject may no longer be sitting at the tip of any branch in the submodule. The hack you are outlining here would not help, and invites "the feature works some of the time (i.e. the commit happens to be at the tip of one of the refs) but fails most of the time" bug reports. So I am not enthused, even though at the technical level, I agree that it is a good "solution" to pretend as if one of the refs were requested after the fetch-pack discovers the refs advertised by the upload-pack. I just fear that it is a wrong approach to solve the real issue and instead make it worse by relieving the pressure from the project and hosting site to configure their repository to support their users properly. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html