Re: Working with remotes with (too) many branches

From: Philip Jägenstedt <philip@foolip.org>
Date: Feb 21, 2012, 22:36 UTC
Message-ID: <CAKHWUkY_bEtKoPOiWFz6i2bp-tbekapROOaCYR0k5Ymh0HYMdA@mail.gmail.com>
In-Reply-To: <7v7gzipkt8.fsf@alter.siamese.dyndns.org>

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

Show 22 quoted lines

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

Show 6 quoted lines

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

Show 15 quoted lines

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

Show 10 quoted lines

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

Show 5 quoted lines

> 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