Partial Clone, and a strange slow rev-list call on fetch

Hi folks,

I'm learning to use Partial Clone, and finding a behavior that I don't know how to interpret or investigate:

Under some circumstances, doing a plain "git fetch <remote>" on a filtered repo results in a very long (6-30 min?) wait, during which I can see the following command being executed in the background:

/usr/libexec/git-core/git rev-list --objects --stdin --exclude-promisor-objects --not --all --quiet --alternate-refs

So far, I have noted this happening under two distinct circumstances:
* Anytime I try to fetch on a filtered repo with a git 2.23 client -
shorter pause
* When I try to fetch with a recent (2.31) client in a repo where one
large packfile has no *.promisor file (but the others do, and the
remote I am fetching from has promisor=true) - looong pause

Can anyone explain what this rev-list call intends, and/or any hints as to how I could see what the stdin content being fed to it from the parent process actually is?

For background, I ended up in the "missing promisor file" situation by trying to be (too?) clever about the blobs present in my clone: I cloned unfiltered shallow to a certain depth with certain refspecs, then added the promisor and filter config, and finally fetched with "--unshallow". This produced exactly the blob-population state I intended, but meant the original first packfile had no ".promisor" file.

Creating an empty promisor file for that packfile *appears* to fix the issue, and hasn't produced any weird side-effects that I've noted, and from the "removing partial clone filtering" description from gitlab at https://docs.gitlab.com/ee/topics/git/partial_clone.html#remove-partial-clone-filtering, appears to be a reasonable thing to do (the implication there is that a promisor packfile with no missing objects hs exactly the same structure as a non-promisor packfile), but of course I would welcome any validation or correction to that assumption.

Thanks for any info, Tao Klerks