From: Philipp Hahn Date: Tue, 16 Sep 2025 17:57:39 GMT Subject: Re: --shallow-exclude=ref -> "ambiguous deepen-not" error Message-ID: <20250916175740.1044452-1-phahn-oss@avm.de> In-Reply-To: Hello Ben, Thank you for your reply. On Tue, 16 Sep 2025 at 13:03:41 -0400 D. Ben Knoble wrote: > On Tue, Sep 16, 2025 at 10:58 AM Philipp Hahn wrote: > > A---B---C topic > > / > > D---E---F---G master > I might have misunderstood, but aren't the commits you're interested > in here the ones named by > > git rev-list master..topic > > ? Yes, which is I have described using `CI_MERGE_REQUEST_TARGET_BRANCH_NAME := master`. 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": > A---B---C topic > / \ > / __X temp > / / > D---E---F---G master Here `master..temp` becomes just "X", but not "A-B-C". I have played with this some more and found another blocker: When using `--shallow-exclude=E` "A" becomes the new _root_-commit, which is then a _crafted_-commit containing *all* files up until "A". What I would need here is to make "E" the _crafted_-commit, so that "A-B-C" remain exactly the same to the not-shallow-clone. > I see a mention of git-clone in the quoted reply, so perhaps you're > trying to avoid cloning too much history. Yes > I wonder if a blobless clone would suffice, which you can then add to once > you have the list of commits produced above? That would fetch more commits > than necessary, but should still be significantly cheaper. That also would be an option – I have not yet tried it out here, but `--filter=tree:0` already worked wonders in one other case. Philipp