{"thread":{"id":"6380","subject":"[PATCH] git-remote exclude","startedAt":"2007-01-14T14:57:26Z","lastAt":"2007-01-17T15:19:35Z","messageCount":10,"participants":["Quy Tonthat","Johannes Schindelin","Andy Parkins","Jakub Narebski","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"31700","messageId":"45AA44D6.6080605@gmail.com","threadId":"6380","inReplyTo":null,"subject":"[PATCH] git-remote exclude","fromName":"Quy Tonthat","fromEmail":"qtonthat@gmail.com","sentAt":"2007-01-14T14:57:26Z","receivedAt":"2007-01-14T14:57:26Z","isPatch":true,"sender":{"key":"qtonthat@gmail.com","avatar":null},"body":"\"git-remote exclude\" can be used to prevent one or more unwanted remote branches\nfrom being tracked. After, for example,\n $ git-remote origin exclude man html\n\"git-fetch origin\" will no longer fetch origin/man and origin/html.\n\n\"git-remote exclude\" does not check whether the \"unwanted\" branch\nreally exists on the remote repo.\n\nSigned-off-by: Quy Tonthat \n---\n git-remote.perl | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 51 insertions(+), 0 deletions(-)\n\ndiff --git a/git-remote.perl b/git-remote.perl\nindex fc055b6..8ee1bea 100755\n--- a/git-remote.perl\n+++ b/git-remote.perl\n@@ -243,6 +243,47 @@ sub add_remote {\n \t\t \"+refs/heads/*:refs/remotes/$name/*\");\n }\n \n+sub exclude_remote_branch {\n+\tmy ($name, @branches) = @_;\n+\tif (!exists $remote->{$name}) {\n+\t\tprint STDERR \"remote $name does not exists.\\n\";\n+\t\texit(1);\n+\t}\n+\n+\tmy $wildcard = \"\";\n+\tmy %fetch_entries = ();\n+\tmy @fetches = $git->command(qw(repo-config --get-all), \"remote.$name.fetch\");\n+\tforeach $fetch (@fetches) {\n+\t\tif ($fetch =~ m%^\\+?refs/heads/\\*:refs/remotes/$name/\\*$%) {\n+\t\t\t$wildcard = $fetch;\n+\t\t}\n+\t\telse {\n+\t\t\tforeach $br (@branches) {\n+\t\t\t\tif ($fetch =~ m#^refs/heads/$br:.*$#) {\n+\t\t\t\t\t$fetch_entries{$br} = $fetch;\n+\t\t\t\t}\n+\t\t\t}\n+\t\t}\n+\t}\n+\n+\tif (!$wildcard) {\n+\t\tprint STDERR \"No wildcard entry for $name. Config not changed\\n\";\n+\t\texit(1);\n+\t}\n+\tmy $clean;\n+ \t($clean = $wildcard) =~ s/([+*])/\\\\$1/g;\n+\t$git->command(qw(repo-config --unset), \"remote.$name.fetch\", $clean);\n+\tforeach $key (keys %fetch_entries) {\n+\t\t$git->command(qw(repo-config --unset), \"remote.$name.fetch\",\n+\t\t\t\t$fetch_entries{$key});\n+\t}\n+\tforeach $br (@branches) {\n+\t\t$git->command(qw(repo-config --add), \"remote.$name.fetch\",\n+\t\t\t\"refs/heads/$br:\");\n+\t}\n+\t$git->command(qw(repo-config --add), \"remote.$name.fetch\", $wildcard);\n+}\n+\n if (!@ARGV) {\n \tfor (sort keys %$remote) {\n \t\tprint \"$_\\n\";\n@@ -274,9 +315,19 @@ elsif ($ARGV[0] eq 'add') {\n \t}\n \tadd_remote($ARGV[1], $ARGV[2]);\n }\n+elsif ($ARGV[0] eq 'exclude') {\n+\tif (@ARGV < 3) {\n+\t\tprint STDERR \"Usage: git remote exclude ...\\n\";\n+\t\texit(1);\n+\t}\n+\tmy @branches = @ARGV;\n+\tshift(@branches); shift(@branches);\n+\texclude_remote_branch($ARGV[1], @branches);\n+}\n else {\n \tprint STDERR \"Usage: git remote\\n\";\n \tprint STDERR \" git remote add \\n\";\n+\tprint STDERR \" git remote exclude ...\\n\";\n \tprint STDERR \" git remote show \\n\";\n \texit(1);\n }\n"},{"id":"31751","messageId":"Pine.LNX.4.63.0701151118400.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6380","inReplyTo":"45AA44D6.6080605@gmail.com","subject":"Re: [PATCH] git-remote exclude","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-15T10:23:12Z","receivedAt":"2007-01-15T10:23:12Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Jan 2007, Quy Tonthat wrote:\n\n> \"git-remote exclude\" can be used to prevent one or more unwanted remote \n> branches from being tracked. After, for example,\n> $ git-remote origin exclude man html\n> \"git-fetch origin\" will no longer fetch origin/man and origin/html.\n\nThat is not what your patch does.\n\nIt rewrites the \"remote.$name.fetch\" entries so that those branches are \nnot _updated_, but they are _fetched_ nevertheless.\n\nBut then, I don't really see _why_ you would want such a solution. After \nall, you are more likely to be interested in _specific_ branches, rather \nthan all branches _except_ a few.\n\nIMHO \"git remote expand \" to expand the wildcards and \"git remote \ncopy \" would be more useful.\n\nCiao,\nDscho\n"},{"id":"31756","messageId":"200701151155.26111.andyparkins@gmail.com","threadId":"6380","inReplyTo":"Pine.LNX.4.63.0701151118400.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] git-remote exclude","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-15T11:55:23Z","receivedAt":"2007-01-15T11:55:23Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 January 15 10:23, Johannes Schindelin wrote:\n\n> But then, I don't really see _why_ you would want such a solution. After\n> all, you are more likely to be interested in _specific_ branches, rather\n> than all branches _except_ a few.\n\nThat's not true. I have a patch (that doesn't work, so it's not submitted), \nthat would allow me to have:\n\n[remote \"origin\"]\n url = git://git2.kernel.org/pub/scm/git/git.git\n fetch = refs/heads/*:refs/remotes/up/*\n fetch = !refs/heads/html\n fetch = !refs/heads/todo\n\ni.e. I don't want those two branches, but I do want everything else. I'd also \nlike to be able to do \"!/refs/heads/temp/*\" so I could block a whole \nsubdirectory of branches. I have a feeling that this would come in handy for \npeople like the person who was recently talking about having 880 branches in \nhis repository, with only a few active.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"31761","messageId":"eogn2u$i8d$1@sea.gmane.org","threadId":"6380","inReplyTo":"200701151155.26111.andyparkins@gmail.com","subject":"Re: [PATCH] git-remote exclude","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-15T20:10:34Z","receivedAt":"2007-01-15T20:10:34Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n> On Monday 2007 January 15 10:23, Johannes Schindelin wrote:\n> \n>> But then, I don't really see _why_ you would want such a solution. After\n>> all, you are more likely to be interested in _specific_ branches, rather\n>> than all branches _except_ a few.\n> \n> That's not true. I have a patch (that doesn't work, so it's not submitted), \n> that would allow me to have:\n> \n> [remote \"origin\"]\n> url = git://git2.kernel.org/pub/scm/git/git.git\n> fetch = refs/heads/*:refs/remotes/up/*\n> fetch = !refs/heads/html\n> fetch = !refs/heads/todo\n> \n> i.e. I don't want those two branches, but I do want everything else. I'd also \n> like to be able to do \"!/refs/heads/temp/*\" so I could block a whole \n> subdirectory of branches. I have a feeling that this would come in handy for \n> people like the person who was recently talking about having 880 branches in \n> his repository, with only a few active.\n\nVery good idea. I even thought that this feature is present in git\nalready...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"31768","messageId":"7vodp00xag.fsf@assigned-by-dhcp.cox.net","threadId":"6380","inReplyTo":"200701151155.26111.andyparkins@gmail.com","subject":"Re: [PATCH] git-remote exclude","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-15T21:56:07Z","receivedAt":"2007-01-15T21:56:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Monday 2007 January 15 10:23, Johannes Schindelin wrote:\n>\n>> But then, I don't really see _why_ you would want such a solution. After\n>> all, you are more likely to be interested in _specific_ branches, rather\n>> than all branches _except_ a few.\n>\n> That's not true. I have a patch (that doesn't work, so it's not submitted), \n> that would allow me to have:\n>\n> [remote \"origin\"]\n> url = git://git2.kernel.org/pub/scm/git/git.git\n> fetch = refs/heads/*:refs/remotes/up/*\n> fetch = !refs/heads/html\n> fetch = !refs/heads/todo\n>\n> i.e. I don't want those two branches, but I do want everything\n> else. I'd also like to be able to do \"!/refs/heads/temp/*\" so\n> I could block a whole subdirectory of branches.\n\nI do not think you are interested in \"not these two but\neverything else\". You are interested in maint, master, next, pu\nand man. You can get away by saying \"not these two but\neverything else\" only because you are implicitly trusting me not\nto publish insane number of random throw-away branches left and\nright.\n\nIn an ideal world, I think you would want to be able to do\nsomething like this:\n\n - Let's look at what they have right now.\n - I want, among the above, this, that and that.\n - I would never want any of the others I just checked.\n\n - If there are new ones found in the future, please let me know\n and I'll decide then. or...\n - If there are new ones found in the future, I would not want to\n be bothered with them. or...\n - If there are new ones found in the future, I want them too.\n\nThe choice between the last three will heavily depend on the\nnature of the project and also your work habit to a certain\ndegree.\n\nA remote could frequently throw in random small-topic branches\nthat are short lived, and are totally uninteresting for somebody\nwho wants to track the big picture branches. You would say the\nfirst if you primarily work in a particular area of the project,\nbecause you will always be interested in the primary integration\nand you may or may not be interested in a new topic. You would\nsay the second if you are only interested in the big picture\nbranches after marking the primary integration branches as\ninteresting. You would say the third only if you are a packrat,\nor have unlimited brain bandwidth to keep track of what's\nhappening in every little corner of the project.\n\nIf a single repository has 1000 branches, that is a sign that\nthere is something wrong in the project's organization. No\nsingle person should need to look at 1000 branches -- that goes\ndirectly against the distributed nature of git. Humans do not\nscale well.\n\nNow, 'git-fetch' currently does not scale either, and I think it\nis a problem, but I think that is fixable by redoing the part\nbelow the while loop that calls append_fetch_head to make the\nprocessing more efficient.\n\nBut you cannot optimize humans the same way.\n\nThe move to BK formalized a change to the development process of\nthe kernel project --- a central single integrator did not scale\nwell, and there was a need for a group of people around the\ncenter to help the peer review and the integration process. The\npatch-flow in the development process places more integration\nwork and responsibility on the lieutenants, and the tool helps\npeople who are more central than the lieutenants trust, verify\nand integrate their lieutenants' work.\n\nHelping this kind of project organization is what git inherited\nfrom BK as well. The key to scaling is to limit the product of\nthe level of details times the size of the area one person needs\nto look at. A project may have 1000 simultaneous development\ngoing at any one time, but a lieutenant should not need to look\nat all 1000 branches but only a much smaller portion of them in\nhis own area of expertise. A more central person should not\nneed to look at all 1000 branches either, but what he will look\nat would be branches that the lieutenants would publish in their\nrepositories, as the result of integration of these 1000\nbranches at the lowest level.\n"},{"id":"31805","messageId":"200701161026.49752.andyparkins@gmail.com","threadId":"6380","inReplyTo":"7vodp00xag.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-remote exclude","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-16T10:26:48Z","receivedAt":"2007-01-16T10:26:48Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 January 15 21:56, Junio C Hamano wrote:\n\n> I do not think you are interested in \"not these two but\n> everything else\". You are interested in maint, master, next, pu\n> and man. You can get away by saying \"not these two but\n> everything else\" only because you are implicitly trusting me not\n> to publish insane number of random throw-away branches left and\n> right.\n\nNope. I think I'm right. You're right that I'm trusting you not to publish \nan insane number of branches, but that holds for the glob-mode only, \nregardless of whether the NOT fetches are in place. The sort of thing I \nimagine happening is that as maintainer you suddenly say - I think 1.5.0 is \nso good that we'll maintain it for longer than usual. In which case we would \nsuddenly get a branch for maint-1.5.0. I would want that branch, but I still \ndon't want man, html and todo.\n\n> - If there are new ones found in the future, please let me know\n> and I'll decide then. or...\n> - If there are new ones found in the future, I would not want to\n> be bothered with them. or...\n> - If there are new ones found in the future, I want them too.\n\n - If there is one that was there but now isn't, ask me if I want to remove\n it\n\n> The choice between the last three will heavily depend on the\n> nature of the project and also your work habit to a certain\n> degree.\n\nTrue; so all those should be possible to specify in the config.\n\n> A remote could frequently throw in random small-topic branches\n> that are short lived, and are totally uninteresting for somebody\n> who wants to track the big picture branches. You would say the\n\nThat's true. However, if there were discipline in the naming, this wouldn't \ncause a major problem:\n\n fetch = refs/heads/export/*:refs/remotes/origin/*\n\nNow, only the branches under export/ will be sent across automatically. You \ncan make whatever topic branches you want without polluting the automatic \nnamespace.\n\n> first if you primarily work in a particular area of the project,\n> because you will always be interested in the primary integration\n> and you may or may not be interested in a new topic. You would\n\nAgain, in a project of that size, the branches could be conventionally stored \nin particular namespaces.\n\n fetch = refs/heads/topicA/*:refs/remotes/origin/topicA/*\n fetch = refs/heads/topicB/*:refs/remotes/origin/topicB/*\n\n> If a single repository has 1000 branches, that is a sign that\n> there is something wrong in the project's organization. No\n> single person should need to look at 1000 branches -- that goes\n> directly against the distributed nature of git. Humans do not\n> scale well.\n\nWithout saying how those 1000 branches are organised, I think that it is an \nincorrect generalisation to say that something is wrong. I have tens of \nthousands of files in my home directory. I cannot possibly look at all those \nfiles; and yet it's not disorganised.\n\nTo me, one of git's strongest features is the ability to have hierarchically \norganised branch names. It solves the scalability problem in one fell swoop.\n\n> But you cannot optimize humans the same way.\n\nNo; but you can optimise them in a different way. Trees are the way, as long \nas the number of choices at any level is within reasonable limits, then you \ncan sort through thousands and thousands of items easily.\n\nI actually think the way to go with this globbing stuff is to make it possible \nto specify more accurately what you want. The weak area at the moment is the \nfact that it's not possible to do a non-recursive glob. That is to say that\n\n fetch = refs/heads/*:refs/remotes/*\n\nwould grab x/foo, y/bar, and z/baz. I know you keep your topic branches in \nplaces like jc/some-topic and js/some-other-topic. If you ever pushed them, \nthen the default glob would pull them all. If we could have a non-recursive \nglob, then you could safely push them (making things all the more \ndistributed) without impacting the master, maint, next, etc branch pulls.\n\n> Helping this kind of project organization is what git inherited\n> from BK as well. The key to scaling is to limit the product of\n> the level of details times the size of the area one person needs\n\nAll agreed. However, limiting the detail is not necessarily the same as \nhiding the detail. If those 1000 branches can be arranged in such a manner \nas to make 990 of them easily ignored, then that's just as good as hiding \nthose 990.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"31811","messageId":"Pine.LNX.4.63.0701161214460.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6380","inReplyTo":"200701161026.49752.andyparkins@gmail.com","subject":"Re: [PATCH] git-remote exclude","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-16T11:16:32Z","receivedAt":"2007-01-16T11:16:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Jan 2007, Andy Parkins wrote:\n\n> On Monday 2007 January 15 21:56, Junio C Hamano wrote:\n> \n> > I do not think you are interested in \"not these two but everything \n> > else\". You are interested in maint, master, next, pu and man. You \n> > can get away by saying \"not these two but everything else\" only \n> > because you are implicitly trusting me not to publish insane number of \n> > random throw-away branches left and right.\n> \n> Nope. I think I'm right. You're right that I'm trusting you not to \n> publish an insane number of branches, but that holds for the glob-mode \n> only, regardless of whether the NOT fetches are in place. The sort of \n> thing I imagine happening is that as maintainer you suddenly say - I \n> think 1.5.0 is so good that we'll maintain it for longer than usual. \n> In which case we would suddenly get a branch for maint-1.5.0. I would \n> want that branch, but I still don't want man, html and todo.\n\nFine. Submit a patch. And if that patch makes git-fetch not as fragile as \nI expect it to do, I am not opposed to inclusion. I'll just not use that \nfeature. And I'll still find your usage confused.\n\nCiao,\nDscho\n"},{"id":"31887","messageId":"45AE2EF8.50403@gmail.com","threadId":"6380","inReplyTo":"Pine.LNX.4.63.0701151118400.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] git-remote exclude","fromName":"Quy Tonthat","fromEmail":"qtonthat@gmail.com","sentAt":"2007-01-17T14:13:12Z","receivedAt":"2007-01-17T14:13:12Z","isPatch":true,"sender":{"key":"qtonthat@gmail.com","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 15 Jan 2007, Quy Tonthat wrote:\n> \n>> \"git-remote exclude\" can be used to prevent one or more unwanted remote \n>> branches from being tracked. After, for example,\n>> $ git-remote origin exclude man html\n>> \"git-fetch origin\" will no longer fetch origin/man and origin/html.\n> \n> That is not what your patch does.\n> \n> It rewrites the \"remote.$name.fetch\" entries so that those branches are \n> not _updated_, but they are _fetched_ nevertheless.\n\nI meant to say \"track\", but somehow \"fetch\" got to my fingers. Old ages, perhaps.\nYou are right, \"update\" is _the_ word. Thanks.\n\n> But then, I don't really see _why_ you would want such a solution.\n> After all, you are more likely to be interested in _specific_ branches, rather \n> than all branches _except_ a few.\n\nFor different situations, there are different paths to choose to reach that\nultimate \"After All\" (Zen? NO!). I offered one (little) path and expect to see\nmore of bigger ones. That's the _why_ (and/or, the _why_ not).\n\nQuy\n"},{"id":"31889","messageId":"45AE3D71.9020708@gmail.com","threadId":"6380","inReplyTo":"Pine.LNX.4.63.0701161214460.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] git-remote exclude","fromName":"Quy Tonthat","fromEmail":"qtonthat@gmail.com","sentAt":"2007-01-17T15:14:57Z","receivedAt":"2007-01-17T15:14:57Z","isPatch":true,"sender":{"key":"qtonthat@gmail.com","avatar":null},"body":"Johannes Schindelin wrote:\n> Fine. Submit a patch. And if that patch makes git-fetch not as fragile as \n> I expect it to do, I am not opposed to inclusion. I'll just not use that \n> feature. And I'll still find your usage confused.\n> \nI have no doubt your opposition to inclusion is important here. But some people\nwould (out-of-fashion'ly/arrogantly/dont-care'ly) submit their patches\n\"just for fun\", as they did in the olden days. (Not that old to me though).\n\nQuy\n"},{"id":"31890","messageId":"Pine.LNX.4.63.0701171618370.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6380","inReplyTo":"45AE3D71.9020708@gmail.com","subject":"Re: [PATCH] git-remote exclude","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-17T15:19:35Z","receivedAt":"2007-01-17T15:19:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Jan 2007, Quy Tonthat wrote:\n\n> Johannes Schindelin wrote:\n> > Fine. Submit a patch. And if that patch makes git-fetch not as fragile as \n> > I expect it to do, I am not opposed to inclusion. I'll just not use that \n> > feature. And I'll still find your usage confused.\n> > \n> I have no doubt your opposition to inclusion is important here. But some people\n> would (out-of-fashion'ly/arrogantly/dont-care'ly) submit their patches\n> \"just for fun\", as they did in the olden days. (Not that old to me though).\n\nHey, if others need that feature, I'm fine! And maybe I find myself in the \nneed of exactly the same feature that I was opposed to, later in my life. \nHappened before, will happen again.\n\nCiao,\nDscho\n"}]}