mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Tao Klerks <>
Subject: Partial Clone, and a strange slow rev-list call on fetch
Date: Wed, 2 Jun 2021 06:56:25 +0200	[thread overview]
Message-ID: <> (raw)

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"

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,
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

             reply	other threads:[~2021-06-02  4:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02  4:56 Tao Klerks [this message]
2021-06-02 11:18 ` Partial Clone, and a strange slow rev-list call on fetch Derrick Stolee
2021-06-03 21:10   ` Tao Klerks
2021-06-04 13:21     ` Derrick Stolee
2021-06-05  6:35       ` Tao Klerks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).