{"thread":{"id":"62978","subject":"Bug or just a mistake : --shallow-exclude parameter behavior anomalies in Git 2.45.2: \"no commits selected\" and \"ambiguous deepen-not\" errors","startedAt":"2025-02-20T08:26:37Z","lastAt":"2025-10-21T12:09:10Z","messageCount":8,"participants":["bolide2005@163.com","Elijah Newren","Philipp Hahn","D. Ben Knoble","Ben Knoble","Erik Cervin Edin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"512757","messageId":"2025022016263355354612@163.com","threadId":"62978","inReplyTo":null,"subject":"Bug or just a mistake : --shallow-exclude parameter behavior anomalies in Git 2.45.2: \"no commits selected\" and \"ambiguous deepen-not\" errors","fromName":"bolide2005@163.com","fromEmail":"bolide2005@163.com","sentAt":"2025-02-20T08:26:34Z","receivedAt":"2025-02-20T08:26:37Z","isPatch":false,"sender":{"key":"bolide2005@163.com","avatar":null},"body":"When using git clone with --shallow-exclude parameter (specifying branch name or existing commit SHA-1), two different errors occur:\n\n\n\n\nCase 1: git clone --shallow-exclude=master \n\n\n\nError: fatal: no commits selected for shallow requests\n\n\n\n\n\nCase 2: git clone --shallow-exclude=ef5974fc470ad7a08f9b58dcd78724e9329910db \n\n\n\nError: git upload-pack: ambiguous deepen-not: deepen-not ef5974fc470ad7a08f9b58dcd78724e9329910db\n\n\n\n\n\nGit Version: 2.45.2 (Confirmed on Centos 7)\n\n\n\n\nbolide2005@163.com\n\n\n"},{"id":"512913","messageId":"CABPp-BEzjk0PLEMjtk-0jQOAag-s_iJkKMbcU+o5vv8BzRVV2A@mail.gmail.com","threadId":"62978","inReplyTo":"2025022016263355354612@163.com","subject":"Re: Bug or just a mistake : --shallow-exclude parameter behavior anomalies in Git 2.45.2: \"no commits selected\" and \"ambiguous deepen-not\" errors","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2025-02-24T15:27:55Z","receivedAt":"2025-02-24T15:28:07Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Feb 20, 2025 at 12:27 AM bolide2005@163.com wrote:\n>\n> When using git clone with --shallow-exclude parameter (specifying branch name or existing commit SHA-1), two different errors occur:\n>\n>\n>\n>\n> Case 1: git clone --shallow-exclude=master \n>\n>\n>\n> Error: fatal: no commits selected for shallow requests\n>\n>\n>\n> Case 2: git clone --shallow-exclude=ef5974fc470ad7a08f9b58dcd78724e9329910db \n>\n>\n>\n> Error: git upload-pack: ambiguous deepen-not: deepen-not ef5974fc470ad7a08f9b58dcd78724e9329910db\n\nThey actually should give different error messages, but the one given\nby the second case, in the version of Git you are using, is broken.\n\nThe error message for case 2 was fixed in 5a875ff7fbd (\"upload-pack:\nfix ambiguous error message\", 2024-11-04).\n\nThe documentation was fixed for case 2 in 00e10e07510 (\"doc: correct\nmisleading descriptions for --shallow-exclude\", 2024-11-04) to point\nout that this usage is flawed.\n\nBoth are part of Git 2.48 and newer.\n"},{"id":"526444","messageId":"20250916145032.969133-1-phahn-oss@avm.de","threadId":"62978","inReplyTo":"CABPp-BEzjk0PLEMjtk-0jQOAag-s_iJkKMbcU+o5vv8BzRVV2A@mail.gmail.com","subject":"Re: --shallow-exclude=ref -> \"ambiguous deepen-not\" error","fromName":"Philipp Hahn","fromEmail":"phahn-oss@avm.de","sentAt":"2025-09-16T14:50:31Z","receivedAt":"2025-09-16T14:58:11Z","isPatch":false,"sender":{"key":"phahn-oss@avm.de","avatar":null},"body":"Hello Elijah,\n\nOn Mon, 24 Feb 2025 at 07:27:55 -0800 Elijah Newren wrote:\n> On Thu, Feb 20, 2025 at 12:27 AM bolide2005@163.com wrote:\n> > Case 2: git clone --shallow-exclude= \n>\n> The documentation was fixed for case 2 in 00e10e07510 (\"doc: correct\n> misleading descriptions for --shallow-exclude\", 2024-11-04) to point\n> out that this usage is flawed.\n\nI have searched the archive and git repository, but found no explanation, why\nthat usage - shallow-exclude by REV - is considered \"flawed\": I understand,\nthat the current implementation does not support this, but is there any\ntechnical reason why that is not possible or undesirable?\n\n A---B---C topic\n /\n D---E---F---G master\n\nI have a use-case for this, where we use GitLab to run some linters on our\nmerge requests (MRs): They examine the commits since the fork-point \"E\", for\nwhich they need access to the commits + trees + blobs. Some MRs are larger,\nsome smaller, so there is no fixed maximum depth I can give to `--depth X` and\nbe sure to have gotten all commits.\nSame for `--shallow-since=` as some are dormant for a year and many other MRs\nby-pass them.\n\nGitLab gives me the `CI_MERGE_REQUEST_DIFF_BASE_SHA`[1] (The base SHA of the\nmerge request diff) for free, which I would like to use with\n`--shallow-exclude=`, but that does not work as `deepen-not` does not like\nREVs.\n\nFor now I'm using `CI_MERGE_REQUEST_TARGET_BRANCH_NAME`[1] (The target branch\nname of the merge request.), but there is a different problem with this:\n\nGitLab supports a 2nd variant of \"MR Pipelines\", called \"Merged Result\nPipelines\"[2]: Instead of running on \"topic\" GitLab does a temporary merge of\n\"topic\" into \"master\" (X) and runs the pipeline on that merge commit \"X\". As\n\"master\" is a parent of that commit \"X\", the trick of using\n`--shallow-exclude=master` fails as the linters then run only on the merge\ncommit \"X\", but not on the individual commits A-B-C, which is what I need:\n\n A---B---C topic\n / \\\n D---E---F---G---X master\n\nSadly there is no \"ref\" on \"E\" any longer, so I only can specify \"E\" via its\n\"rev\", which GitLab provides as `CI_MERGE_REQUEST_DIFF_BASE_SHA`.\n\nAny idea on how to solve this?\n\nThe GitLab runners do not have persistent storage, so they clone the git\nrepository anew each time. That includes the Linux Kernel git, which sometimes\ntakes 13m to clone the 1.4e6 commits, from which only the top 1-100 have to be\nchecked.\nThe build on the other hand only needs `--depth 1`. That makes the build way\nfaster than running out linters.\n\nPhilipp\n\n[1]: https://docs.gitlab.com/ci/variables/predefined_variables/#predefined-variables-for-merge-request-pipelines\n[2]: https://docs.gitlab.com/ci/pipelines/merged_results_pipelines/\n\n"},{"id":"526458","messageId":"CALnO6CAbUNgp6n4kYg1ATCC1mHa7Z2m3d7FZwaYrgtkMLWR3-w@mail.gmail.com","threadId":"62978","inReplyTo":"20250916145032.969133-1-phahn-oss@avm.de","subject":"Re: --shallow-exclude=ref -> \"ambiguous deepen-not\" error","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-09-16T17:03:41Z","receivedAt":"2025-09-16T17:03:54Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Tue, Sep 16, 2025 at 10:58 AM Philipp Hahn wrote:\n>\n> Hello Elijah,\n>\n> On Mon, 24 Feb 2025 at 07:27:55 -0800 Elijah Newren wrote:\n> > On Thu, Feb 20, 2025 at 12:27 AM bolide2005@163.com wrote:\n> > > Case 2: git clone --shallow-exclude= \n> >\n> > The documentation was fixed for case 2 in 00e10e07510 (\"doc: correct\n> > misleading descriptions for --shallow-exclude\", 2024-11-04) to point\n> > out that this usage is flawed.\n>\n> I have searched the archive and git repository, but found no explanation, why\n> that usage - shallow-exclude by REV - is considered \"flawed\": I understand,\n> that the current implementation does not support this, but is there any\n> technical reason why that is not possible or undesirable?\n>\n> A---B---C topic\n> /\n> D---E---F---G master\n>\n> I have a use-case for this, where we use GitLab to run some linters on our\n> merge requests (MRs): They examine the commits since the fork-point \"E\", for\n> which they need access to the commits + trees + blobs. Some MRs are larger,\n> some smaller, so there is no fixed maximum depth I can give to `--depth X` and\n> be sure to have gotten all commits.\n> Same for `--shallow-since=` as some are dormant for a year and many other MRs\n> by-pass them.\n\nI might have misunderstood, but aren't the commits you're interested\nin here the ones named by\n\n git rev-list master..topic\n\n?\n\nI see a mention of git-clone in the quoted reply, so perhaps you're\ntrying to avoid cloning too much history. I wonder if a blobless clone\nwould suffice, which you can then add to once you have the list of\ncommits produced above? That would fetch more commits than necessary,\nbut should still be significantly cheaper.\n\n-- \nD. Ben Knoble\n"},{"id":"526465","messageId":"20250916175740.1044452-1-phahn-oss@avm.de","threadId":"62978","inReplyTo":"CALnO6CAbUNgp6n4kYg1ATCC1mHa7Z2m3d7FZwaYrgtkMLWR3-w@mail.gmail.com","subject":"Re: --shallow-exclude=ref -> \"ambiguous deepen-not\" error","fromName":"Philipp Hahn","fromEmail":"phahn-oss@avm.de","sentAt":"2025-09-16T17:57:39Z","receivedAt":"2025-09-16T17:59:42Z","isPatch":false,"sender":{"key":"phahn-oss@avm.de","avatar":null},"body":"Hello Ben,\n\nThank you for your reply.\n\nOn Tue, 16 Sep 2025 at 13:03:41 -0400 D. Ben Knoble wrote:\n> On Tue, Sep 16, 2025 at 10:58 AM Philipp Hahn wrote:\n> > A---B---C topic\n> > /\n> > D---E---F---G master\n\n> I might have misunderstood, but aren't the commits you're interested\n> in here the ones named by\n> \n> git rev-list master..topic\n> \n> ?\n\nYes, which is I have described using `CI_MERGE_REQUEST_TARGET_BRANCH_NAME :=\nmaster`.\n\nBut as also described this fails for those \"merged regsult pipelines\", where GitLab creates a temporary merge \"X\" and then runs its pipeline on \"X\":\n\n> A---B---C topic\n> / \\\n> / __X temp\n> / /\n> D---E---F---G master\n\nHere `master..temp` becomes just \"X\", but not \"A-B-C\".\n\nI have played with this some more and found another blocker: When using\n`--shallow-exclude=E` \"A\" becomes the new _root_-commit, which is then a\n_crafted_-commit containing *all* files up until \"A\".\nWhat I would need here is to make \"E\" the _crafted_-commit, so that \"A-B-C\"\nremain exactly the same to the not-shallow-clone.\n\n\n> I see a mention of git-clone in the quoted reply, so perhaps you're\n> trying to avoid cloning too much history.\n\nYes\n\n> I wonder if a blobless clone would suffice, which you can then add to once\n> you have the list of commits produced above? That would fetch more commits\n> than necessary, but should still be significantly cheaper.\n\nThat also would be an option – I have not yet tried it out here, but\n`--filter=tree:0` already worked wonders in one other case.\n\nPhilipp\n"},{"id":"526493","messageId":"7A5A29A3-3738-4BD6-ADB2-F3D1DE355B80@gmail.com","threadId":"62978","inReplyTo":"20250916175740.1044452-1-phahn-oss@avm.de","subject":"Re: --shallow-exclude=ref -> \"ambiguous deepen-not\" error","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-09-16T20:34:15Z","receivedAt":"2025-09-16T20:34:27Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"\n> Le 16 sept. 2025 à 13:59, Philipp Hahn a écrit :\n> \n> Hello Ben,\n> \n> Thank you for your reply.\n> \n>> On Tue, 16 Sep 2025 at 13:03:41 -0400 D. Ben Knoble wrote:\n>>> On Tue, Sep 16, 2025 at 10:58 AM Philipp Hahn wrote:\n>>> A---B---C topic\n>>> /\n>>> D---E---F---G master\n> \n>> I might have misunderstood, but aren't the commits you're interested\n>> in here the ones named by\n>> \n>> git rev-list master..topic\n>> \n>> ?\n> \n> Yes, which is I have described using `CI_MERGE_REQUEST_TARGET_BRANCH_NAME :=\n> master`.\n> \n> But as also described this fails for those \"merged regsult pipelines\", where GitLab creates a temporary merge \"X\" and then runs its pipeline on \"X\":\n> \n>> A---B---C topic\n>> / \\\n>> / __X temp\n>> / /\n>> D---E---F---G master\n> \n> Here `master..temp` becomes just \"X\", but not \"A-B-C\".\n\nHere you should still use master..topic if you want to lint each individual commit, plus include temp if you want to lint the merge. "},{"id":"526538","messageId":"CABPp-BFxqJt+2HbY+d_qdZ0w=UDaL_u4MzO_3cpPpArQHREBJA@mail.gmail.com","threadId":"62978","inReplyTo":"20250916145032.969133-1-phahn-oss@avm.de","subject":"Re: --shallow-exclude=ref -> \"ambiguous deepen-not\" error","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2025-09-17T02:54:16Z","receivedAt":"2025-09-17T02:54:30Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Sep 16, 2025 at 7:52 AM Philipp Hahn wrote:\n>\n> Hello Elijah,\n>\n> On Mon, 24 Feb 2025 at 07:27:55 -0800 Elijah Newren wrote:\n> > On Thu, Feb 20, 2025 at 12:27 AM bolide2005@163.com wrote:\n> > > Case 2: git clone --shallow-exclude= \n> >\n> > The documentation was fixed for case 2 in 00e10e07510 (\"doc: correct\n> > misleading descriptions for --shallow-exclude\", 2024-11-04) to point\n> > out that this usage is flawed.\n>\n> I have searched the archive and git repository, but found no explanation, why\n> that usage - shallow-exclude by REV - is considered \"flawed\": I understand,\n> that the current implementation does not support this, but is there any\n> technical reason why that is not possible or undesirable?\n\nI'd honestly rather not touch shallow clones, I only did so because of\nuser reports and their obvious confusion from the misleading\ndocumentation and error message that existed at the time.\n\nAnyway, I wasn't making any judgement call on what might be a\ndesirable implementation. I was just noting that the current\nimplementation is guaranteed to do nothing useful with such a flag,\nand thus that passing such a flag with the current code is flawed, and\nsadly that our documentation misled users and our code gave a less\nthan helpful error message in such cases. I fixed up the\ndocumentation and error messages to fit the current implementation.\n\nHope that helps clarify my intent and focus at the time.\n"},{"id":"529261","messageId":"CA+JQ7M9svLSV_CSu9OK8hO7rj3GtMQA953tTP=AOta40JTCNCQ@mail.gmail.com","threadId":"62978","inReplyTo":"CABPp-BFxqJt+2HbY+d_qdZ0w=UDaL_u4MzO_3cpPpArQHREBJA@mail.gmail.com","subject":"Re: --shallow-exclude=ref -> \"ambiguous deepen-not\" error","fromName":"Erik Cervin Edin","fromEmail":"erik@cervined.in","sentAt":"2025-10-21T12:08:33Z","receivedAt":"2025-10-21T12:09:10Z","isPatch":false,"sender":{"key":"erik@cervined.in","avatar":null},"body":"Hi!\n\nI just wanted to add some personal experiences to this thread.\n\nOn Tue, Sep 16, 2025 at 4:58 PM Philipp Hahn wrote:\n>\n> I have a use-case for this, where we use GitLab to run some linters on our\n> merge requests (MRs): They examine the commits since the fork-point \"E\", for\n> which they need access to the commits + trees + blobs. Some MRs are larger,\n> some smaller, so there is no fixed maximum depth I can give to `--depth X` and\n> be sure to have gotten all commits.\n> Same for `--shallow-since=` as some are dormant for a year and many other MRs\n> by-pass them.\n\nI have a very similar use-case to Philipp. Except my forge is GitHub\nand not quite the same challenges w. temporary merge commits.\nBasically we run commitlinter on origin/master..HEAD in each PR. The\nGitHub action does a shallow clone with depth=1 and it looks like\ncommitlinter uses git log under the hood, and as a consequence ends up\nonly running the linter on HEAD. I found --shallow-exclude and thought\nI would give that a try (to make sure we have the commits\norigin/master..HEAD). However I encounter a different issue when\nrunning the command\n\n # Test 1: shallow-exclude=master FAILS\n cd /tmp\n git clone --depth=1 https://github.com/git/git.git test-master\n cd test-master\n git rev-list --count --all # Shows: 1 commit\n git fetch --shallow-exclude=master origin\n # Result: fatal: the remote end hung up unexpectedly ❌\n\n # Test 2: shallow-exclude=maint WORKS\n cd /tmp\n git clone --depth=1 https://github.com/git/git.git test-maint\n cd test-maint\n git rev-list --count --all # Shows: 1 commit\n git fetch --shallow-exclude=maint origin\n # Result: SUCCESS, now has 43 commits ✅\n\nOriginally I thought deepen-not wasn't supported by the GitHub server\nbut I was very surprised seeing it work for maint. No idea of what's\ngoing wrong here actually. Some searches pointed in the direction of\nchanging the postBuffer configuration (which seems odd).\n\nI'll probably go a different route but I wanted to share my\nexperiences in the thread as there was not a lot of information around\nwhich helped me understand what was going wrong.\n"}]}