On Sun, Feb 19, 2012 at 22:36, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Philip Jägenstedt <philip@xxxxxxxxxx> 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 -- 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