{"thread":{"id":"29667","subject":"Working with remotes with (too) many branches","startedAt":"2012-02-19T15:29:57Z","lastAt":"2012-02-21T22:47:30Z","messageCount":5,"participants":["Philip Jägenstedt","Junio C Hamano","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"184948","messageId":"CAKHWUka763XRWyMz2Xq1qQ2rfKqSYdTX0xtdVFm8zWJ_+6tGqA@mail.gmail.com","threadId":"29667","inReplyTo":null,"subject":"Working with remotes with (too) many branches","fromName":"Philip Jägenstedt","fromEmail":"philip@foolip.org","sentAt":"2012-02-19T15:29:57Z","receivedAt":"2012-02-19T15:29:57Z","isPatch":false,"sender":{"key":"philip@foolip.org","avatar":"https://avatars.githubusercontent.com/u/498917?v=4"},"body":"Hi,\n\nI work on a project where topic branches are allowed in the main\nrepository and are not removed even if/when they are merged. This\nresults in an ever-growing number of branches (and tags), making e.g.\ntab completion slow to the point of being useless. We know that this\nis not great and it will probably change, but in the meantime I have\nset up an alternative origin that only includes the master branch and\nannotated tags. However, I still need to collaborate on some topic\nbranches in the main repository, and have arrived at this solution:\n\n$ git remote add -t footopic -f --no-tags main example.com:/git/main.git\n$ git checkout -t main/footopic\n# next day\n$ git remote set-branches --add main bartopic\n$ git fetch main\n$ git checkout -t main/bartopic\n\nThis works fairly well, but there are a few wrinkles:\n\n1. If I make a typo with remote set-branches, fetch will fail with\n\"fatal: Couldn't find remote ref refs/heads/typotopic\" and not fetch\nanything at all.\n\n2. If I forget that I've previously worked with footopic and\nset-branches --add it again, I'll get a duplicate line in my config.\n\n3. When I don't care about footopic anymore, there's no clear way to\nstop fetching it and remove refs/remotes/main/footopic.\n\n4. If set-branches --delete existed one could end up with no fetch\nlines in the remote config, at which point fetch falls back to\nfetching HEAD, instead of the expected nothing.\n\n1 and 2 seem fairly easy to fix: add set-branches --delete and use the\nsame logic to make --add also remove duplicates. Would changing the\ngit_config_set_multivar call in add_branch (remote.c) be the right\nkind of fix here?\n\n3 is less clear to me. Is it a bug that fetch --prune only prunes refs\nthat it actually tried to fetch, or is it remote prune that should be\ntaking care of this? Alternatively, should it be the non-existent\nset-branches --delete?\n\n4 could be a deliberate fallback, or is it a bug waiting to be exposed?\n\nI'd appreciate feedback on these issues so that I don't waste time\ntrying to patch the wrong problems. Suggestions for an alternative\nwork flow is of course also most welcome!\n\n--\nPhilip Jägenstedt\n"},{"id":"184952","messageId":"7v7gzipkt8.fsf@alter.siamese.dyndns.org","threadId":"29667","inReplyTo":"CAKHWUka763XRWyMz2Xq1qQ2rfKqSYdTX0xtdVFm8zWJ_+6tGqA@mail.gmail.com","subject":"Re: Working with remotes with (too) many branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-19T21:36:35Z","receivedAt":"2012-02-19T21:36:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Jägenstedt <philip@foolip.org> writes:\n\n> 1. If I make a typo with remote set-branches, fetch will fail with\n> \"fatal: Couldn't find remote ref refs/heads/typotopic\" and not fetch\n> anything at all.\n\nAt that point you can notice the earlier typo and remove or fix the fetch\nrefspec you have.\n\nAlternatively, set-branches could run ls-remote against the remote and\nnotice that there is no such branch over there. However, even if you got\nthe branch name right when you did \"set-branches\", you would still see the\nsame \"Couldn't find\" when the branch gets removed over there, so you would\nneed a way to remove or fix the fetch refspec you have *anyway*.\n\nSo, assuming that there is no easy way to remove one branch from the set\nof branches tracked from a given remote, it is much more important to add\nsuch a way.  Checking against a typo when \"set-branches\" is run is \"nicer\nto have\" but lack of it is not a show-stopper.\n\nWouldn't \"git config --unset remote.origin.fetch '/typotopic'\" be\nsufficient in the meantime even if a user fears \"vi .git/config\"?\n\n> 2. If I forget that I've previously worked with footopic and\n> set-branches --add it again, I'll get a duplicate line in my config.\n\nI do not know the duplicate hurts anything, but I agree that it would be\nmore aescetically pleasing if \"--add\" noticed what you already had and\navoided duplicates.\n\n> 3. When I don't care about footopic anymore, there's no clear way to\n> stop fetching it and remove refs/remotes/main/footopic.\n\nIsn't the lack of \"set-branches --delete\" the same as #1 above?  The\nlatter would be \"branch -r -d main/footopic\" but I could imagine\n\"set-branches --delete\" would do that for you once implemented.\n\n> 4. If set-branches --delete existed one could end up with no fetch\n> lines in the remote config, at which point fetch falls back to\n> fetching HEAD, instead of the expected nothing.\n\nDon't do that, then ;-)\n\nI could imagine a new preference \"fetch.$remote.default=nothing\" that\ncauses \"git fetch\" to fail with \"You have fetch.$remote.default=nothing\nset, so I am not fetching anything from there without any configured\nrefspec\".  The default would be fetch.$remote.default=HEAD, I would guess.\n\nThe preference can be set automatically when you use \"set-branches\"\nwithout \"--add\" for a given remote, as use of \"set-branches\" is a clear\nindication that you want to deviate from the built-in default behaviour\nwhen interacting with that remote.\n\n> I'd appreciate feedback on these issues so that I don't waste time\n> trying to patch the wrong problems. Suggestions for an alternative\n> work flow is of course also most welcome!\n\nAdmittedly I wouldn't use \"set-branches\" myself (it is far easier to tweak\nwith \"vi .git/config\", and I wasn't involved in), but looking at the whole\nhistory of the feature with \"git log --grep=set-branch builtin/remote.c\",\nI have a feeling that not many people used, cut by its still-unrounded\nedges, and polished the subcommand by rounding them out yet, and it has a\nlarge room for improvement.\n\nIt would have saved you time to wait for a round-trip if you did the above\n\"git log\" yourself to find out from whom this subcommand came from, and\nlooked at list archive to see if the original author is still active here\n(in this case he is), and Cc'ed him before posting the message I am\nresponding to.\n"},{"id":"185111","messageId":"CAKHWUkY_bEtKoPOiWFz6i2bp-tbekapROOaCYR0k5Ymh0HYMdA@mail.gmail.com","threadId":"29667","inReplyTo":"7v7gzipkt8.fsf@alter.siamese.dyndns.org","subject":"Re: Working with remotes with (too) many branches","fromName":"Philip Jägenstedt","fromEmail":"philip@foolip.org","sentAt":"2012-02-21T22:36:25Z","receivedAt":"2012-02-21T22:36:25Z","isPatch":false,"sender":{"key":"philip@foolip.org","avatar":"https://avatars.githubusercontent.com/u/498917?v=4"},"body":"On Sun, Feb 19, 2012 at 22:36, Junio C Hamano <gitster@pobox.com> wrote:\n> Philip Jägenstedt <philip@foolip.org> writes:\n>\n>> 1. If I make a typo with remote set-branches, fetch will fail with\n>> \"fatal: Couldn't find remote ref refs/heads/typotopic\" and not fetch\n>> anything at all.\n>\n> At that point you can notice the earlier typo and remove or fix the fetch\n> refspec you have.\n>\n> Alternatively, set-branches could run ls-remote against the remote and\n> notice that there is no such branch over there. However, even if you got\n> the branch name right when you did \"set-branches\", you would still see the\n> same \"Couldn't find\" when the branch gets removed over there, so you would\n> need a way to remove or fix the fetch refspec you have *anyway*.\n>\n> So, assuming that there is no easy way to remove one branch from the set\n> of branches tracked from a given remote, it is much more important to add\n> such a way.  Checking against a typo when \"set-branches\" is run is \"nicer\n> to have\" but lack of it is not a show-stopper.\n>\n> Wouldn't \"git config --unset remote.origin.fetch '/typotopic'\" be\n> sufficient in the meantime even if a user fears \"vi .git/config\"?\n\nYeah, one can recover if one knows what config \"set-branches\" maps to,\nbut I'd like this to be less error-prone so that I can recommend it to\nothers suffering from branch explosion. Tab completion and\n\"set-branches --remove\" is probably a good start.\n\n>> 2. If I forget that I've previously worked with footopic and\n>> set-branches --add it again, I'll get a duplicate line in my config.\n>\n> I do not know the duplicate hurts anything, but I agree that it would be\n> more aescetically pleasing if \"--add\" noticed what you already had and\n> avoided duplicates.\n\nRight, it's not worthwhile by itself, but something to consider if\nimplementing --delete.\n\n>> 3. When I don't care about footopic anymore, there's no clear way to\n>> stop fetching it and remove refs/remotes/main/footopic.\n>\n> Isn't the lack of \"set-branches --delete\" the same as #1 above?\n\nKind of, several of these points can be solved by the same fixes.\n\n> The\n> latter would be \"branch -r -d main/footopic\" but I could imagine\n> \"set-branches --delete\" would do that for you once implemented.\n\nLetting \"set-branches --delete\" manage this per-branch would be nice, I agree.\n\nWould it be wrong, though, if \"fetch --prune\" and \"remote prune\"\nsimply pruned all refs under refs/remotes/main/ that were not fetched?\nIt seems to me that if one starts out with all branches and then\n\"set-branches main footopic\", one really does want all other refs to\ngo away on the next fetch.\n\n>> 4. If set-branches --delete existed one could end up with no fetch\n>> lines in the remote config, at which point fetch falls back to\n>> fetching HEAD, instead of the expected nothing.\n>\n> Don't do that, then ;-)\n>\n> I could imagine a new preference \"fetch.$remote.default=nothing\" that\n> causes \"git fetch\" to fail with \"You have fetch.$remote.default=nothing\n> set, so I am not fetching anything from there without any configured\n> refspec\".  The default would be fetch.$remote.default=HEAD, I would guess.\n>\n> The preference can be set automatically when you use \"set-branches\"\n> without \"--add\" for a given remote, as use of \"set-branches\" is a clear\n> indication that you want to deviate from the built-in default behaviour\n> when interacting with that remote.\n\nThat sounds like a good idea. To make sure that I understand the\nnotation, the actual config would look something like this:\n\n[remote \"origin\"]\n\turl = git://github.com/gitster/git.git\n\t# no fetch, it was removed\n\n[fetch \"origin\"]\n\tdefault = nothing\n\nThis looks a bit odd to me, shouldn't the new setting file under\n[remote \"origin\"]?\n\n>> I'd appreciate feedback on these issues so that I don't waste time\n>> trying to patch the wrong problems. Suggestions for an alternative\n>> work flow is of course also most welcome!\n>\n> Admittedly I wouldn't use \"set-branches\" myself (it is far easier to tweak\n> with \"vi .git/config\", and I wasn't involved in), but looking at the whole\n> history of the feature with \"git log --grep=set-branch builtin/remote.c\",\n> I have a feeling that not many people used, cut by its still-unrounded\n> edges, and polished the subcommand by rounding them out yet, and it has a\n> large room for improvement.\n\nThat was my impression as well.\n\n> It would have saved you time to wait for a round-trip if you did the above\n> \"git log\" yourself to find out from whom this subcommand came from, and\n> looked at list archive to see if the original author is still active here\n> (in this case he is), and Cc'ed him before posting the message I am\n> responding to.\n\nThanks for the tip. (I did look at the original commit and search the\narchives, but found no answers.)\n\n-- \nPhilip Jägenstedt\n"},{"id":"185112","messageId":"20120221224303.GB31934@burratino","threadId":"29667","inReplyTo":"CAKHWUkY_bEtKoPOiWFz6i2bp-tbekapROOaCYR0k5Ymh0HYMdA@mail.gmail.com","subject":"Re: Working with remotes with (too) many branches","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-02-21T22:43:03Z","receivedAt":"2012-02-21T22:43:03Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Philip,\n\nPhilip Jägenstedt wrote:\n\n> It seems to me that if one starts out with all branches and then\n> \"set-branches main footopic\", one really does want all other refs to\n> go away on the next fetch.\n\nI would expect set-branches to remove the remote-tracking branches\nthat are no longer relevant itself, actually.\n\nMartin, does this seem sensible to you?  If so, I'll be happy to look\ninto it in the next few days (or I'll be even happier someone else\ngets to it first).\n\nHope that helps,\nJonathan\n"},{"id":"185113","messageId":"7vwr7ferct.fsf@alter.siamese.dyndns.org","threadId":"29667","inReplyTo":"CAKHWUkY_bEtKoPOiWFz6i2bp-tbekapROOaCYR0k5Ymh0HYMdA@mail.gmail.com","subject":"Re: Working with remotes with (too) many branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-21T22:47:30Z","receivedAt":"2012-02-21T22:47:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Jägenstedt <philip@foolip.org> writes:\n\n> This looks a bit odd to me, shouldn't the new setting file under\n> [remote \"origin\"]?\n\nYeah, remote.$name.fetchDefault or something.\n\n> Thanks for the tip. (I did look at the original commit and search the\n> archives, but found no answers.)\n\nHeh, it does say --delete # not implemented ;-)\n"}]}