Working with remotes with (too) many branches

Hi,

I work on a project where topic branches are allowed in the main repository and are not removed even if/when they are merged. This results in an ever-growing number of branches (and tags), making e.g. tab completion slow to the point of being useless. We know that this is not great and it will probably change, but in the meantime I have set up an alternative origin that only includes the master branch and annotated tags. However, I still need to collaborate on some topic branches in the main repository, and have arrived at this solution:

$ git remote add -t footopic -f --no-tags main example.com:/git/main.git $ git checkout -t main/footopic # next day $ git remote set-branches --add main bartopic $ git fetch main $ git checkout -t main/bartopic

This works fairly well, but there are a few wrinkles:

1. If I make a typo with remote set-branches, fetch will fail with
"fatal: Couldn't find remote ref refs/heads/typotopic" and not fetch
anything at all.

2. If I forget that I've previously worked with footopic and
set-branches --add it again, I'll get a duplicate line in my config.

3. When I don't care about footopic anymore, there's no clear way to
stop fetching it and remove refs/remotes/main/footopic.

4. If set-branches --delete existed one could end up with no fetch
lines in the remote config, at which point fetch falls back to
fetching HEAD, instead of the expected nothing.

1 and 2 seem fairly easy to fix: add set-branches --delete and use the same logic to make --add also remove duplicates. Would changing the git_config_set_multivar call in add_branch (remote.c) be the right kind of fix here?

3 is less clear to me. Is it a bug that fetch --prune only prunes refs that it actually tried to fetch, or is it remote prune that should be taking care of this? Alternatively, should it be the non-existent set-branches --delete?

4 could be a deliberate fallback, or is it a bug waiting to be exposed?

I'd appreciate feedback on these issues so that I don't waste time trying to patch the wrong problems. Suggestions for an alternative work flow is of course also most welcome!

-- Philip Jägenstedt