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

Philip Jägenstedt <philip@foolip.org> writes:

At that point you can notice the earlier typo and remove or fix the fetch refspec you have.

Alternatively, set-branches could run ls-remote against the remote and notice that there is no such branch over there. However, even if you got the branch name right when you did "set-branches", you would still see the same "Couldn't find" when the branch gets removed over there, so you would need a way to remove or fix the fetch refspec you have *anyway*.

So, assuming that there is no easy way to remove one branch from the set of branches tracked from a given remote, it is much more important to add such a way. Checking against a typo when "set-branches" is run is "nicer to have" but lack of it is not a show-stopper.

Wouldn't "git config --unset remote.origin.fetch '/typotopic'" be sufficient in the meantime even if a user fears "vi .git/config"?

I do not know the duplicate hurts anything, but I agree that it would be more aescetically pleasing if "--add" noticed what you already had and avoided duplicates.

Isn't the lack of "set-branches --delete" the same as #1 above? The latter would be "branch -r -d main/footopic" but I could imagine "set-branches --delete" would do that for you once implemented.

Don't do that, then ;-)

I could imagine a new preference "fetch.$remote.default=nothing" that causes "git fetch" to fail with "You have fetch.$remote.default=nothing set, so I am not fetching anything from there without any configured refspec". The default would be fetch.$remote.default=HEAD, I would guess.

The preference can be set automatically when you use "set-branches" without "--add" for a given remote, as use of "set-branches" is a clear indication that you want to deviate from the built-in default behaviour when interacting with that remote.

Admittedly I wouldn't use "set-branches" myself (it is far easier to tweak with "vi .git/config", and I wasn't involved in), but looking at the whole history of the feature with "git log --grep=set-branch builtin/remote.c", I have a feeling that not many people used, cut by its still-unrounded edges, and polished the subcommand by rounding them out yet, and it has a large room for improvement.

It would have saved you time to wait for a round-trip if you did the above "git log" yourself to find out from whom this subcommand came from, and looked at list archive to see if the original author is still active here (in this case he is), and Cc'ed him before posting the message I am responding to.

On Sun, Feb 19, 2012 at 22:36, Junio C Hamano <gitster@pobox.com> wrote:

Yeah, one can recover if one knows what config "set-branches" maps to, but I'd like this to be less error-prone so that I can recommend it to others suffering from branch explosion. Tab completion and "set-branches --remove" is probably a good start.

Right, it's not worthwhile by itself, but something to consider if implementing --delete.

Kind of, several of these points can be solved by the same fixes.

Letting "set-branches --delete" manage this per-branch would be nice, I agree.

Would it be wrong, though, if "fetch --prune" and "remote prune" simply pruned all refs under refs/remotes/main/ that were not fetched? It seems to me that if one starts out with all branches and then "set-branches main footopic", one really does want all other refs to go away on the next fetch.

That sounds like a good idea. To make sure that I understand the notation, the actual config would look something like this:

[remote "origin"]
	url = git://github.com/gitster/git.git
	# no fetch, it was removed

[fetch "origin"]
	default = nothing

This looks a bit odd to me, shouldn't the new setting file under [remote "origin"]?

That was my impression as well.

Thanks for the tip. (I did look at the original commit and search the archives, but found no answers.)

Hi Philip,

Philip Jägenstedt wrote:

I would expect set-branches to remove the remote-tracking branches that are no longer relevant itself, actually.

Martin, does this seem sensible to you? If so, I'll be happy to look into it in the next few days (or I'll be even happier someone else gets to it first).

Hope that helps, Jonathan

Philip Jägenstedt <philip@foolip.org> writes:

Yeah, remote.$name.fetchDefault or something.

Heh, it does say --delete # not implemented ;-)