Re: --shallow-exclude=ref -> "ambiguous deepen-not" error

From: Philipp Hahn <phahn-oss@avm.de>
Date: Sep 16, 2025, 17:57 UTC
Message-ID: <20250916175740.1044452-1-phahn-oss@avm.de>
In-Reply-To: <CALnO6CAbUNgp6n4kYg1ATCC1mHa7Z2m3d7FZwaYrgtkMLWR3-w@mail.gmail.com>

Hello Ben,

Thank you for your reply.

On Tue, 16 Sep 2025 at 13:03:41 -0400 D. Ben Knoble <ben.knoble@gmail.com> wrote:

> On Tue, Sep 16, 2025 at 10:58 AM Philipp Hahn <phahn-oss@avm.de> wrote:
> >                      A---B---C topic
> >                     /
> >                D---E---F---G master

Show 6 quoted lines

> 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":

Show 5 quoted lines

>                      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