Derrick Stolee <derrickstolee@xxxxxxxxxx> 于2022年9月2日周五 03:18写道： > > On 9/1/2022 5:41 AM, ZheNing Hu via GitGitGadget wrote: > > From: ZheNing Hu <adlternative@xxxxxxxxx> > > > > In repo_parse_commit_internal(), if we want to use > > commit graph, it will call parse_commit_in_graph() to > > parse commit's content from commit graph, otherwise > > call repo_read_object_file() to parse commit's content > > from commit object. > > > > repo_read_object_file() will respect commit graft, > > which can correctly amend commit's parents. But > > parse_commit_in_graph() not. Inconsistencies here may > > result in incorrect processing of shallow clone. > > > > So let parse_commit_in_graph() respect commit graft as > > repo_read_object_file() does, which can solve this problem. > > If grafts or replace-objects exist, then the commit-graph > is disabled and this code will never be called. I would > expect a test case demonstrating the change in behavior > here, but that is impossible. > Thanks for the clarification. I don't really know what's the wrong here, but just let do a little test: 1. Revert this commit 19fd72c34dcd1332df638d76b0b028e9d9da3d41 $ git revert 19fd72 2. Clone the git repo $ git clone --bare git@xxxxxxxxxx:git/git.git 3. Write commit graph $ git commit-graph write 4. Use the depth=<depth> to clone (depth=1) $ git clone --no-checkout --no-local --=depth=1 git.git git1 Cloning into 'git1'... remote: Enumerating objects: 4306, done. remote: Counting objects: 100% (4306/4306), done. remote: Compressing objects: 100% (3785/3785), done. 4. Use the depth=<depth> to clone (depth=2) $ git clone --no-checkout --no-local --=depth=2 git.git git2 Cloning into 'git2'... remote: Enumerating objects: 4311, done. remote: Counting objects: 100% (4311/4311), done. remote: Compressing objects: 100% (3788/3788), done. 5. Use the depth filter to clone (depth=1) $ git clone --no-checkout --no-local --filter=depth:1 git.git git3 Cloning into 'git3'... remote: Enumerating objects: 4306, done. remote: Counting objects: 100% (4306/4306), done. remote: Compressing objects: 100% (3785/3785), done. 6. Use the depth filter to clone (depth=2) $ git clone --no-checkout --no-local --filter=depth:2 git.git git4 Cloning into 'git4'... remote: Enumerating objects: 322987, done. remote: Counting objects: 100% (322987/322987), done. remote: Compressing objects: 100% (77441/77441), done. As we can see, when we use --filter=depth:<depth> (depth >= 2), it seems like we clone a lot of objects. The result is significantly different from git clone --depth=<depth> (depth >= 2). So I debug it by reproducing the git pack-objects process: I find there are different action between --filter=depth:<depth> and --depth=<depth> . --filter=depth:<depth> will be successfully resolved commit parents in parse_commit_in_graph(), Call stack( cmd_pack_objects -> get_object_list -> traverse_commit_list -> traverse_commit_list_filtered -> do_traverse -> get_revision -> get_revision_internal -> get_revision_1 -> process_parents -> repo_parse_commit_gently -> repo_parse_commit_internal -> parse_commit_in_graph) --depth=<depth> will failed in parse_commit_in_graph(), and call repo_read_object_file() to resolved commit parents. Call stack( cmd_pack_objects -> get_object_list -> traverse_commit_list -> traverse_commit_list_filtered -> do_traverse -> get_revision -> get_revision_internal -> get_revision_1 -> process_parents -> repo_parse_commit_gently -> repo_parse_commit_internal -> repo_read_object_file) > The commit-graph parsing should not be bogged down with > this logic. > So I try to fix this problem by let commit-graph respect commit-graft. I don't know if I overlook something before... > Thanks, > -Stolee > Thanks, ZheNing Hu
