The moment I started staring at clone times
The first time I tracked our slowest CI job back to git clone, I felt a little betrayed. All the caching we had done, all the parallelism we had bought, and the pipeline was still sitting there dragging down years of history so a linter could look at three files. My reaction was some version of: how is this still the default.
Turns out I am not alone. On August 18, 2026, GitLab's engineering blog put out a post with an almost-cathartic title, "Avoid the massive end-to-end tax of default full history clones". It argues something operators who tune runners have quietly known for a while. Defaulting to a full-history clone at the start of every pipeline is a real, cumulative tax on end-to-end time. And the post floats a clone override policy as a way to bring that cost down.
I am going to send you to the source for the specifics of the policy they are pitching. What I want to unpack here is why this framing lands, and what levers you already have today, whether or not you adopt any specific proposal.
Why "just clone the repo" gets expensive
Git clone is not one operation. It is a network fetch of every commit, every tree and every blob in the repository history, wrapped in a pack negotiation. On a young repo you never notice. On one that has been around for a while, especially with heavy binaries, generated files or vendored dependencies in the history, it is the difference between a job starting in seconds and a job starting in minutes.
Now multiply that. Every job in your pipeline. Every parallel job in a matrix. Every retry. Every merge-request pipeline that fires on push. The tax GitLab is pointing at scales with fanout, not with any single clone. Twenty parallel jobs each cloning full history mean you paid for that history twenty times before any real work started.
There is a second-order cost that hides well. Full clones make runners hungrier: more disk, more RAM to pack and index, more time in the network stage where nothing observable to the user is happening. That last one shows up as flat time in a flame graph and it is very easy to ignore, because you cannot point at a bad test to blame.
The knobs that already exist
You do not have to wait for a new policy to trim clone time. Git itself gives you three well-known moves:
- Shallow clone.
git clone --depth=1fetches only the tip of the ref you asked for. It is the biggest single win for jobs that only need the current tree, which is most jobs. - Blobless clone.
git clone --filter=blob:noneuses the partial-clone protocol to defer file contents until you actually read them. History and directory structure come down cheaply; blobs stream in on demand. - Treeless clone.
git clone --filter=tree:0is the same idea one level more aggressive. Trees arrive only as needed. Fine when a job just wants a single ref and a build command.
Most CI systems expose these behind their own controls. GitLab CI has GIT_STRATEGY and GIT_DEPTH. GitHub Actions' actions/checkout exposes fetch-depth and a filter input for partial clones. The rest of the ecosystem sits on the same git primitives with different wrappers.
The interesting question is not whether these knobs exist. It is which default your platform ships with, and who has the authority to change it. A clone override policy is, in the end, an argument about defaults: whether the runner or the pipeline author gets the last word on how much history to pull.
What to watch out for
Shallow and partial clones are almost free until they are not. A job that runs git log past the truncation point suddenly has to backfill history. A tool that walks the whole tree for provenance or ownership will trigger a slow network round-trip mid-job. Anything that resolves a merge base against a distant commit will feel the change.
The mitigation is boring and it works. Know which jobs actually need history and give them a deeper checkout. Everyone else runs with --depth=1 or a blobless filter. If your pipeline template exposes a single full_history toggle that a job author has to opt into with a reason in the review, you get most of the win without breaking the one job that legitimately walks back to 2018.
Caching is worth a look too. Runners that reuse a workspace between jobs can turn the full-history cost into a one-time cost, then keep the local .git warm across runs. It is one of those cases where doing more work up front, once, buys you a lot of quiet later.
What I am watching next
I do not know yet how many teams will actually shift their defaults on the back of a single blog post. Old defaults are sticky, and there is always one job somewhere that needs git blame all the way down. What I am hoping for is the meta-conversation the post nudges into the open: your pipeline's slowest stage might be one line of runner config away from being invisible.
If your team has not looked at clone time this quarter, look. Grab a slow job, print the elapsed time of the git stage, and check whether you are pulling years of history to run three seconds of work. Then tell me what you found.
