For git clone, I am using the argument --filter=blob:none. This works for my use case.

Turns out, filtering is an optional server side feature. I learned this when I came across a server which doesn't support this, and to my surprise the git client downloaded everything anyway!!

$ git clone --single-branch --depth=1 --no-checkout --filter=blob:none ...
Cloning into `...`
warning: filtering not recognized by server, ignoring
warning: filtering not recognized by server, ignoring
remote: Couting objects: 12345, done.
Receiving objects: 99% ...

This is undesirable behavior which should NOT happen. Is there a way of:

• querying a git server ahead of time to ensure that filtering is enabled before cloning
• making this "warning" instead fatal; the git clone command should fail and not pull any remote files

Thanks.

For git clone, I am using the argument --filter=blob:none. This works for my use case.

Turns out, filtering is an optional server side feature. I learned this when I came across a server which doesn't support this, and to my surprise the git client downloaded everything anyway!!

$ git clone --single-branch --depth=1 --no-checkout --filter=blob:none ...
Cloning into `...`
warning: filtering not recognized by server, ignoring
warning: filtering not recognized by server, ignoring
remote: Couting objects: 12345, done.
Receiving objects: 99% ...

This is undesirable behavior which should NOT happen. Is there a way of:

• querying a git server ahead of time to ensure that filtering is enabled before cloning
• making this "warning" instead fatal; the git clone command should fail and not pull any remote files

Thanks.

• git
• filter
• clone

• I have submitted a patch: github/gitgitgadget/git/pull/1869 – jagprog5 Commented Mar 1 at 21:33

1 Answer 1

querying a git server ahead of time to ensure that filtering is enabled before cloning

No convenient method, but you can try doing that with:

GIT_TRACE_PACKET=1 git ls-remote <url>

For remotes supporting Git protocol v2 there will be a ls-remote< line that looks like:

ls-remote< fetch=shallow wait-for-done filter

For protocol v1 remotes, all of that data is crammed into the 1st ref entry:

ls-remote< asdfghjkl HEAD\0multi_ack ... allow-reachable-sha1-in-want filter ...

For testing purposes you can see this with git -c protocol.version=1 ls-remote, or by testing against any personal SSH server.

(The 'allow-reachable-sha1-in-want' feature is also required, so that Git could later request individual objects for on-demand download.)

making this "warning" instead fatal; the git clone command should fail and not pull any remote files

No, current versions of git do not have that option.