Working with remotes with (too) many branches

Working with remotes with (too) many branches

[Philip Jägenstedt]

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

Re: Working with remotes with (too) many branches

[Junio C Hamano]

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

> 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.

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"?

> 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.

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.

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

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.

> 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.

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.

> 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!

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.

Re: Working with remotes with (too) many branches

[Philip Jägenstedt]

On Sun, Feb 19, 2012 at 22:36, Junio C Hamano <gitster@pobox.com> wrote:
> Philip Jägenstedt <philip@foolip.org> writes:
>
>> 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.
>
> 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"?

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.

>> 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.
>
> 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.

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

>> 3. When I don't care about footopic anymore, there's no clear way to
>> stop fetching it and remove refs/remotes/main/footopic.
>
> Isn't the lack of "set-branches --delete" the same as #1 above?

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

> The
> latter would be "branch -r -d main/footopic" but I could imagine
> "set-branches --delete" would do that for you once implemented.

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.

>> 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.
>
> 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.

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"]?

>> 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!
>
> 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.

That was my impression as well.

> 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.

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

-- 
Philip Jägenstedt

Re: Working with remotes with (too) many branches

[Jonathan Nieder]

Hi Philip,

Philip Jägenstedt wrote:

> 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.

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

Re: Working with remotes with (too) many branches

[Junio C Hamano]

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

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

Yeah, remote.$name.fetchDefault or something.

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

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