On 24/03/22 04.08, Jonathan Tan wrote:
However, this is not the case when fetching with --update-shallow. In post_assign_shallow() in shallow.c, a revision walk is done that also parses commits at the shallow boundary before updating the shallow information (and hence, the graft information). (This revision walk needs to be done before the update because the nature of the update depends on the outcome of the revision walk.) If we were to revision-walk such a commit (at the shallow boundary), we would end up trying and failing to parse its parents because its list of parents is not empty (since it was parsed before there was any graft information telling us to conceal its parents). This revision walk will happen if the client has submodules, as it will revision-walk the fetched commits to check for new submodules, triggering this bug.
What about fetching with --deepen? Will "unintended" unshallowing with --update-shallow possibly happen if --update-shallow is used, as opposed to --depth/--deepen? -- An old man doll... just what I always wanted! - Clara
