jj git fetch does not delete tags that were deleted on remote

[necauqua]

Description

A bit of an idiosyncratic setup, but on my work the monorepo has tags for every commit in the last 30 days. This even does make some sense actually - it's for people knowing which revision is newer, the tags are just sequential revision numbers used in CI/CD.
Tags older than 30d are deleted.

After a few months like that, gitlab just started completely hanging at the end of my push.
git push had identical behaviour, and with it I observed this

λ bat ../git-trace.txt | rg 'push>.*?refs/tags' -c
3565
λ bat ../git-trace.txt | rg 'push<.*?refs/tags' -c
1381

Freshly re-cloned monorepo did not have any push> lines, and the push worked fine.

So both jj and git try to push the local tags, or at least negotiate something about them, I'm not too sure what do those lines mean, and gitlab didn't like that.
Doing git tag -d $(git tag -l) to delete all local tags (and then jj git fetch to refetch currently-existing remote tags) fixed the issue completely.

[PhilipMetzger]

cc @bsdinis since you've changed the behavior there.

[bsdinis]

@necauqua does this just happen with git2 or with subprocessing?

[necauqua]

Nope, I never used the new subprocessing thing.
Default fetch/push worked well enough on this monorepo

Just realised that yeah, I can enable git.subrocess so that git does the fetching, that will probably fix this

[bsdinis]

Let me know if it does.
In any case, I don't think this is a bug, but a feature request to prune tags

[bsdinis]

Just realised that yeah, I can enable git.subrocess so that git does the fetching, that will probably fix this

If you rebuild main it should have it by default :-)