From: Philipp Hahn Date: Tue, 16 Sep 2025 14:50:31 GMT Subject: Re: --shallow-exclude=ref -> "ambiguous deepen-not" error Message-ID: <20250916145032.969133-1-phahn-oss@avm.de> In-Reply-To: Hello Elijah, On Mon, 24 Feb 2025 at 07:27:55 -0800 Elijah Newren wrote: > On Thu, Feb 20, 2025 at 12:27 AM bolide2005@163.com wrote: > > Case 2: git clone --shallow-exclude= > > The documentation was fixed for case 2 in 00e10e07510 ("doc: correct > misleading descriptions for --shallow-exclude", 2024-11-04) to point > out that this usage is flawed. I have searched the archive and git repository, but found no explanation, why that usage - shallow-exclude by REV - is considered "flawed": I understand, that the current implementation does not support this, but is there any technical reason why that is not possible or undesirable? A---B---C topic / D---E---F---G master I have a use-case for this, where we use GitLab to run some linters on our merge requests (MRs): They examine the commits since the fork-point "E", for which they need access to the commits + trees + blobs. Some MRs are larger, some smaller, so there is no fixed maximum depth I can give to `--depth X` and be sure to have gotten all commits. Same for `--shallow-since=` as some are dormant for a year and many other MRs by-pass them. GitLab gives me the `CI_MERGE_REQUEST_DIFF_BASE_SHA`[1] (The base SHA of the merge request diff) for free, which I would like to use with `--shallow-exclude=`, but that does not work as `deepen-not` does not like REVs. For now I'm using `CI_MERGE_REQUEST_TARGET_BRANCH_NAME`[1] (The target branch name of the merge request.), but there is a different problem with this: GitLab supports a 2nd variant of "MR Pipelines", called "Merged Result Pipelines"[2]: Instead of running on "topic" GitLab does a temporary merge of "topic" into "master" (X) and runs the pipeline on that merge commit "X". As "master" is a parent of that commit "X", the trick of using `--shallow-exclude=master` fails as the linters then run only on the merge commit "X", but not on the individual commits A-B-C, which is what I need: A---B---C topic / \ D---E---F---G---X master Sadly there is no "ref" on "E" any longer, so I only can specify "E" via its "rev", which GitLab provides as `CI_MERGE_REQUEST_DIFF_BASE_SHA`. Any idea on how to solve this? The GitLab runners do not have persistent storage, so they clone the git repository anew each time. That includes the Linux Kernel git, which sometimes takes 13m to clone the 1.4e6 commits, from which only the top 1-100 have to be checked. The build on the other hand only needs `--depth 1`. That makes the build way faster than running out linters. Philipp [1]: https://docs.gitlab.com/ci/variables/predefined_variables/#predefined-variables-for-merge-request-pipelines [2]: https://docs.gitlab.com/ci/pipelines/merged_results_pipelines/