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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html