Working with remotes with (too) many branches

["Philip Jägenstedt" <philip@foolip.org>]

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