TL;DR: use --depth 2. Read on for why.

Shallow clones (can, but not necessarily must) defeat an important optimization. In your case this happens for the first push, but not for subsequent pushes. Other defeating cases can occur so other pushes might also be slow.

We start with the fact that Git is really all about commits,¹ which are shaped into a Directed Acyclic Graph. The graph has vertices or nodes—whichever term you prefer—that are numbered, by commit hash IDs. Relatively immaterial here, but helpful for concreteness, is the fact that the edges / arcs between the nodes are stored as part of the nodes themselves, rather than being kept separately. Each node stores the hash IDs of its predecessor nodes.

A repository is, at heart, a database of these commit objects. A complete—non-shallow—repository has the entire graph, from every root to every tip commit. A single-branch clone potentially drops some part of the graph, but never has any “gaps” in the graph. For instance, given:

           node--node--tip1
          /
root--node
          
           node--node--tip2

we can drop either tip and the nodes on that row, but not the nodes and root on the middle row. In all of these cases, then, we can—as Git always does—start at the tip and work backwards and eventually arrive at the root.

Now, there are two properties of each node that are important here:

• The number is unique. It’s a universally unique ID. No node in any other Git repository (that we’ll meet anyway) can re-use that ID.

• The data in the node are strictly read-only. That includes the outgoing edge links.

What this means is that if we have a gap-free repository—one that’s either totally complete, or at least as complete as required for the tip commits it contains—on each side of a sender-to-receiver operation, we can have the sending repository simply enumerate for us some set of commits, by their numbers. If we, the