> I just freshly compiled from 'next' branch: > > > git version > git version 2.28.0.rc1.139.gd6b33fda9d > > And the problem still occurring: > > mkdir scalar > > cd scalar > > git init > Initialized empty Git repository in /Users/sluongngoc/work/booking/core/scalar/.git/ > # use my own fork here so that i have push permission > > git remote add origin git@xxxxxxxxxx:sluongng/scalar.git > > git sparse-checkout init --cone > > git fetch --filter=tree:0 --no-tags --prune origin 4ba6c1c090e6e5a413e3ac2fc094205bd78f761e > remote: Enumerating objects: 2553, done. > remote: Total 2553 (delta 0), reused 0 (delta 0), pack-reused 2553 > Receiving objects: 100% (2553/2553), 957.85 KiB | 1.06 MiB/s, done. > Resolving deltas: 100% (74/74), done. > From github.com:sluongng/scalar > * branch 4ba6c1c090e6e5a413e3ac2fc094205bd78f761e -> FETCH_HEAD > > git tag -a test-tag -m 'test tag message' 4ba6c1c090e6e5a413e3ac2fc094205bd78f761e > > git push origin refs/tags/test-tag:refs/tags/test-tag > ...<download start> Thanks for the reproduction steps. Is 4ba6c1c advertised as a ref by the remote? If not, what is probably happening is that the client doesn't realize that the server already has 4ba6c1c, so the client needs to fetch 4ba6c1c's objects to send it to the server. I am planning to see if I can add batch prefetching to pack-objects to reduce the severity of similar situations (just one batch prefetch instead of many one-by-one fetches), although that would work better with a blob filter instead of a tree filter.
