Use --filter=tree:0 for git clone in Duo Workflows behind feature flag
What does this MR do and why?
Use --filter=tree:0 for git clone in Duo Workflows behind feature flag
Switch GIT_FETCH_EXTRA_FLAGS from --filter=blob:none to --filter=tree:0 and change the shallow_clone default from true to false when the dap_git_tree_zero_option feature flag is enabled. This avoids the performance penalty that shallow clone and blob-filter impose on subsequent git push operations.
- Feature flag issue: [FF] `dap_git_tree_zero_option` -- Rollout or -... (#595729)
- Issue: DAP: Investigate slow git pushes for shallow cl... (#595704)
Analysis
All clones target git@gitlab.com:gitlab-org/gitlab.git from the same machine.
| Clone options | Wall time | Shallow? | Expected push time |
|---|---|---|---|
--depth 1 |
28.9s | yes | ~400s (timeout) |
--depth 2 |
30.0s | yes | ~400s (timeout) |
--filter=tree:0 |
1m 16s | no | ~5s |
--filter=blob:none |
3m 10s | no | ~5s |
| no filter (full clone) | 6m 07s | no | ~5s |
--filter=tree:0 is the best tradeoff:
- Not shallow no
shallowpkt-line on push, so push completes in ~5s - Fast to clone 1m16s, 6x faster than
--filter=blob:noneand 13x faster than a full clone - Working tree is fully materialized only historical tree/blob objects are absent; the checkout at HEAD works normally
Git downloads only commit objects during clone, skipping tree and blob objects for all historical commits. Only the tip commit's trees and blobs are fetched to populate the working tree.
This is more aggressive than --filter=blob:none, which downloads all commits and trees but skips blobs. --filter=tree:0 already implies blob exclusion for historical commits, so combining the two filters is redundant.
Tradeoffs
Commands that walk history and inspect paths will trigger lazy fetches of missing tree objects on first use:
git log -- lib/api/users.rb
git blame lib/api/users.rb
git diff HEAD~50 -- lib/api/users.rbThese fetches are transparent and cached locally after the first run. For a Duo agent workflow (read working tree, make changes, commit, push, inspect recent history), this is not a practical concern deep history traversal across many paths is not a typical operation.