Re: Working with remotes with (too) many branches

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 19, 2012, 21:36 UTC
Message-ID: <7v7gzipkt8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAKHWUka763XRWyMz2Xq1qQ2rfKqSYdTX0xtdVFm8zWJ_+6tGqA@mail.gmail.com>

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.