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

["D. Ben Knoble" <ben.knoble@gmail.com>]

On Tue, Sep 16, 2025 at 10:58 AM Philipp Hahn <phahn-oss@avm.de> wrote:
>
> Hello Elijah,
>
> On Mon, 24 Feb 2025 at 07:27:55 -0800 Elijah Newren <newren@gmail.com> wrote:
> > On Thu, Feb 20, 2025 at 12:27 AM bolide2005@163.com <bolide2005@163.com> wrote:
> > > Case 2: git clone --shallow-exclude=<rev> <repo-url>
> >
> > 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.

I might have misunderstood, but aren't the commits you're interested
in here the ones named by

    git rev-list master..topic

?

I see a mention of git-clone in the quoted reply, so perhaps you're
trying to avoid cloning too much history. 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.

-- 
D. Ben Knoble