{"thread":{"id":"21684","subject":"Android needs repo, Chrome needs gclient. Neither work. What does that say about git?","startedAt":"2009-11-20T10:51:32Z","lastAt":"2009-11-24T20:45:42Z","messageCount":10,"participants":["Adrian May","Johannes Schindelin","Petr Baudis","Jakub Narebski","Clemens Buchacher","tytso@mit.edu","Bob Hazard","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"128000","messageId":"65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com","threadId":"21684","inReplyTo":"2d707e8c-2561-470c-beba-c81e16ac441c@k17g2000yqh.googlegroups.com","subject":"Android needs repo, Chrome needs gclient. Neither work. What does that say about git?","fromName":"Adrian May","fromEmail":"adrian.alexander.may@gmail.com","sentAt":"2009-11-20T10:51:32Z","receivedAt":"2009-11-20T10:51:32Z","isPatch":false,"sender":{"key":"adrian.alexander.may@gmail.com","avatar":null},"body":"Git is just plain wrong, because you can't split or merge repositories\nor pull subtrees of them. It doesn't have the kind of triggers you\nneed to assert change control either, and these bolt-on scripts are\njust making life messy. Will somebody please finish git itself instead\nof working around it, or use a source control system that's up to the\njob.\n\nAdrian.\n\nPS: In both cases, I had problems pulling the code.\n"},{"id":"128007","messageId":"alpine.DEB.1.00.0911201229080.4985@pacific.mpi-cbg.de","threadId":"21684","inReplyTo":"65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com","subject":"Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-20T11:31:43Z","receivedAt":"2009-11-20T11:31:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Nov 2009, Adrian May wrote:\n\n> Git is just plain wrong, because you can't split or merge repositories\n> or pull subtrees of them.\n\nYou are plain wrong, because that is possible.  Did you maybe forget to do \nyour homework before coming here and shouting around as if you were right?\n\n> It doesn't have the kind of triggers you need to assert change control \n> either, and these bolt-on scripts are just making life messy.\n\nTo the contrary, these \"bolt-on scripts\" are superior to other solutions, \nbecause they give the savvy user freedom to do _anything_ a program can \ndo.\n\n> Will somebody please finish git itself instead of working around it, or \n> use a source control system that's up to the job.\n\nYou obviously do not understand Open Source.  If you have an itch, scratch \nit, or pay somebody to scratch it for you.\n\n> PS: In both cases, I had problems pulling the code.\n\nIf you had problems pulling the code, there are two possible sources of \nproblems: the program or a PEBCAK.\n\nCiao,\nDscho\n\nP.S.: Feels fine to vent for me, too.\n"},{"id":"128009","messageId":"20091120115056.GP17748@machine.or.cz","threadId":"21684","inReplyTo":"65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com","subject":"Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2009-11-20T11:50:56Z","receivedAt":"2009-11-20T11:50:56Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, Nov 20, 2009 at 06:51:32PM +0800, Adrian May wrote:\n> It doesn't have the kind of triggers you\n> need to assert change control either, and these bolt-on scripts are\n> just making life messy.\n\nCan you elaborate?\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"128012","messageId":"m3y6m1bbxg.fsf@localhost.localdomain","threadId":"21684","inReplyTo":"65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com","subject":"Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-20T12:46:39Z","receivedAt":"2009-11-20T12:46:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Adrian May <adrian.alexander.may@gmail.com> writes:\n\n> Git is just plain wrong, because you can't split or merge repositories\n> or pull subtrees of them. It doesn't have the kind of triggers you\n> need to assert change control either, and these bolt-on scripts are\n> just making life messy. Will somebody please finish git itself instead\n> of working around it, or use a source control system that's up to the\n> job.\n\nYour complaing have the same sense as complaining that gcc does not\ninclude functionality of Makefile, because you just can't manage\nlarger projects without it (or equivalent).\n\nDo one thing, and do it well.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"128023","messageId":"20091120155847.GA1359@localhost","threadId":"21684","inReplyTo":"65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com","subject":"Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2009-11-20T15:58:47Z","receivedAt":"2009-11-20T15:58:47Z","isPatch":false,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Fri, Nov 20, 2009 at 06:51:32PM +0800, Adrian May wrote:\n> Git is just plain wrong, because you can't split or merge repositories\n> or pull subtrees of them.\n\nI think you made an unfortunate choice of words here, because as others have\nmentioned, splitting and merging subtrees is implemented already. Maybe you\nwere talking about checking out or cloning subtrees. To date, none of the\ndistributed version control systems are capable of doing that. And that is\none of the reasons why we have wrapper scripts like repo (although IIRC repo\ndoes a lot more than just that).\n\nAFAICS, there is no fundamental reason why this should be difficult to\nsupport. Clearly, there are some odd situations to deal with. For example,\nhow to deal with merge conflicts that happen outside of the subtree that's\ncurrently available? How to detect (modified) moves of files into the\navailable subtree?\n\nBut we could simply fail in these cases. The workarounds currently in use\nare not able to do this either.\n\n> It doesn't have the kind of triggers you need to assert change control\n> either, and these bolt-on scripts are just making life messy.\n\nI don't understand what you mean here.\n\n> Will somebody please finish git itself instead of working around it, or\n> use a source control system that's up to the job.\n\nThere is a desire to do this in the git community, as documented in [1].\nHowever, it appears to be hard enough to do so that people had rather\nimplement custom solutions such as git-submodules, which are probably just\ngood enough for them.\n\nClemens\n\n[1] http://git.or.cz/gitwiki/SoC2009Ideas#NarrowandSparseclonesupport\n"},{"id":"128148","messageId":"65e170e70911222011l776a6aean7bd75f072a806616@mail.gmail.com","threadId":"21684","inReplyTo":"alpine.DEB.1.00.0911201229080.4985@pacific.mpi-cbg.de","subject":"Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?","fromName":"Adrian May","fromEmail":"adrian.alexander.may@gmail.com","sentAt":"2009-11-23T04:11:29Z","receivedAt":"2009-11-23T04:11:29Z","isPatch":false,"sender":{"key":"adrian.alexander.may@gmail.com","avatar":null},"body":">> Git is just plain wrong, because you can't split or merge repositories\n>> or pull subtrees of them.\n>\n> You are plain wrong, because that is possible.  Did you maybe forget to do\n> your homework before coming here and shouting around as if you were right?\n\nSo it is. Fair enough, I stand corrected. That was my single biggest\ngripe about git so it's nice to know it's there.\n\n> To the contrary, these \"bolt-on scripts\" are superior to other solutions,\n> because they give the savvy user freedom to do _anything_ a program can\n> do.\n> Your complaing have the same sense as complaining that gcc does not\n> include functionality of Makefile, because you just can't manage\n> larger projects without it (or equivalent).\n\nWell, these scripts, whatever git is written in and pretty much\neverything else in sight is a Turing machine, so anything could, in\ntheory, do anything. But nevertheless, I think everybody agrees that\ncertain functions belong in certain places, even if they disagree\nabout where. I'd wager that 'make' belongs outside of gcc because it\nalso drives other compilers, things like yacc, post-build steps, etc.\nOTOH I think producing browse info is a long-standing ommission from\ngcc that should never have been done externally in things like ctags\nand cscope, because the compiler has to do 90% of the work required\nanyway and because it's the compiler's opinion that counts.\n\nAs for gclient and repo, without pretending to be an expert on what\nthey actually do, I'm getting a strong gut feeling that if what I'm\ntrying to do is pull or push code, then that's about as close as you\ncan get to a definition of source control's central purpose. In the\ndays of cvs or svn, I'd expect to use the source control for that. How\ncome git needs help? Basically, my point is that these scripts should\nbe the roadmap for git itself, because those are the functions people\nhad to add to their git-based set-up in the real world. Also because\nthe implementations would probably be simpler, more robust and more\ngeneral if they were in git.\n\n> these \"bolt-on scripts\" give the savvy user freedom\n\nActually, I think their purpose is precisely the opposite: to regiment\nthe ordinary developer into following their process. So having that\ncode under the developer's control is a weakness.\n\nAs for pulling subtrees, I guess it's sensible for the code managers\nto declare which subtrees are likely to work on their own by making\nthem repositories. I believe you can also link lots of repositories\ntogether to make a huge combo-repository, so I don't understand why\nandroid doesn't use that instead of having this script to iterate over\nthem all. Maybe they started before the split/merge thing got written\n(it would have been risky to try and get it right first time if they\ncouldn't rearrange them later.)\n\n>> It doesn't have the kind of triggers you\n>> need to assert change control either, and these bolt-on scripts are\n>> just making life messy.\n>Can you elaborate?\n\nWell, I believe that repo is largely about asserting their code\nintegration process. It knows who to send your changes to for review.\nBut now that I think about it, I guess git does that as a first\nprinciple. If I push to your repo, you get to review it before it goes\nin and in the meantime I shouldn't be surprised that our repos look\ndifferent. So what the hell do they write those scripts for? Does\nanybody around here know if they actually need them or not?\nUnfortunately their list doesn't seem to be taking my post.\n\n> If you had problems pulling the code, there are two possible sources of\n> problems: the program or a PEBCAK.\n\nWell, the repo thing eventually got fixed: it was committing suicide\nat the first sign of server load. I don't know what gclient's problem\nis, but my personal opinion is that the *root* problem is the\nexistence of the scripts at all. In both cases, there's not much room\nfor pebcak in the instructions.\n\n> You obviously do not understand Open Source.  If you have an itch, scratch\n> it, or pay somebody to scratch it for you.\n\nI know, but I'm actually supposed to be getting on with my real job\ninstead of sticking my nose into other peoples' problems like this. I\nmight also argue that making suggestions is some kind of contribution,\nat least if the value of the suggestion outweighs the distraction of\neverybody having to read it to find out whether it's any use or not,\nwhich may or may not be the case here. Either way, I also have a\nbudget for distractions and it doesn't allow for getting my brain\naround the git source code.\n\nAdrian.\n"},{"id":"128172","messageId":"20091123135817.GB2532@thunk.org","threadId":"21684","inReplyTo":"65e170e70911222011l776a6aean7bd75f072a806616@mail.gmail.com","subject":"Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?","fromName":"","fromEmail":"tytso@mit.edu","sentAt":"2009-11-23T13:58:17Z","receivedAt":"2009-11-23T13:58:17Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Nov 23, 2009 at 12:11:29PM +0800, Adrian May wrote:\n> As for gclient and repo, without pretending to be an expert on what\n> they actually do, I'm getting a strong gut feeling that if what I'm\n> trying to do is pull or push code, then that's about as close as you\n> can get to a definition of source control's central purpose. In the\n> days of cvs or svn, I'd expect to use the source control for that. How\n> come git needs help?\n\n> > these \"bolt-on scripts\" give the savvy user freedom\n> \n> Actually, I think their purpose is precisely the opposite: to regiment\n> the ordinary developer into following their process. So having that\n> code under the developer's control is a weakness.\n\nIf you don't have bolt-on scripts, and you move that into the the core\nSCM, then you force *all* projects to use whatever workflow was\ndecided as being the One True Way of doing things as seen by the SCM\ndesigner.  So the question is whether the SCM *should* regiment all\nprojects into following the SCM's designers idea of the One True\nWorkflow.\n\nGit's approach is to say that it will be fairly flexible about\ndictating workflow --- who pushs to whom; whether there is a single\n\"star\" repository topology, or something that is more flexible, etc.\n\nYou seem to hate this flexibility, because it makes life harder until\nyou set up these bolt-on scripts.  But that's what many of us like\nabout git; that it doesn't force us (the project lead) into a single\nway of doing things.\n\nAs far as my wanting to impose a particular regimen on my project's\ndevelopers, I've never been a big fan of the Bondage and Discpline\nschool of software engineering.  They can use whatever workflow they\nlike; they just have to deliver patches that are clean.  If they are,\nI'll pull from their repository.  If they aren't, I won't.\n\n     \t       \t     \t\t     \t  \t    - Ted\n"},{"id":"128227","messageId":"65e170e70911231948l3b032dbeu7c99b65ce3ec97ff@mail.gmail.com","threadId":"21684","inReplyTo":"20091123135817.GB2532@thunk.org","subject":"Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?","fromName":"Adrian May","fromEmail":"adrian.alexander.may@gmail.com","sentAt":"2009-11-24T03:48:09Z","receivedAt":"2009-11-24T03:48:09Z","isPatch":false,"sender":{"key":"adrian.alexander.may@gmail.com","avatar":null},"body":"> If you don't have bolt-on scripts, and you move that into the the core\n> SCM, then you force *all* projects to use whatever workflow was\n> decided as being the One True Way of doing things as seen by the SCM\n> designer.  So the question is whether the SCM *should* regiment all\n> projects into following the SCM's designers idea of the One True\n> Workflow.\n\nOf course I'd want the workflow configurable by whoever controls the\nmain repository. I couldn't possibly suggest that all git projects\nneed the same workflow. The number of developers can vary by five\norders of magnitude - that calls for different workflow models.\n\n> Git's approach is to say that it will be fairly flexible about\n> dictating workflow --- who pushs to whom; whether there is a single\n> \"star\" repository topology, or something that is more flexible, etc.\n> You seem to hate this flexibility, because it makes life harder until\n> you set up these bolt-on scripts.  But that's what many of us like\n> about git; that it doesn't force us (the project lead) into a single\n> way of doing things.\n\nLeaving aside topology, I suppose we can agree that the subject\ndivides into two aspects: offering the developer some optional tools,\nand asserting control over what gets commited to the official repo.\nPerhaps we can also agree that the former belongs under the control of\nthe developer and the latter should be in the PM's hands. You seem to\nhave opinions about which of these two aspects is more or less\nimportant, and to what extent git suffices, but I don't. I assume that\nthe project manager has his own opinions about both aspects and I'm\nobserving two big projects that independantly have augmented git's\nfeatures with their own scripts. Their docs talk about both aspects,\nespecially repo's, but they are entirely implemented in\ndeveloper-overridable scripts. So any repo functions to do with the\nsecond aspect are either features that git needs to grow, or bits of\nthe git manual that the repo designer didn't read. I'd kinda like to\nknow which.\n\nReturning to topology, I think that also divides up similarly. The PM\ncan't forbid you and me from casually swapping diffs back and forth,\nbut he can dictate who we are supposed to submit our final candidate\nto for review. The very existence of a PM, who controls a subset of\nthe repositories in the world, already implies a star topology, and I\nthink pretty much everybody is using distributed source control in\nthis way, at least when it comes down to *controlling* anything.\nPeople may also be causally bouncing diffs around, but that's not\ncontrol, it's communication. I've got a one-man project on github\nwhich I edit from two locations, and even on that scale I find myself\nworking star-fashion because either computer might have junk\nexperiments in progress, but I only push to github if it's meaningful\nand tidy.\n\nThat reminds me of a slightly different question: if a longer\nexperiment that I have committed several stages of turns out to be a\nblind alley, I'd like to go back a few steps on main, declare\neverything after that to be a side branch that I'll probably never use\nagain, and continue on main with my next attempt. Is that possible? I\nknow that I can just start a new branch from the before the bad\nexperiment, but if that happens a lot, the name of my current main\nbranch would be changing all the time, and I think that's bad. I\nsuspect what I want is possible, but I'm not sure how to do it.\n\n> As far as my wanting to impose a particular regimen on my project's\n> developers, I've never been a big fan of the Bondage and Discpline\n> school of software engineering.  They can use whatever workflow they\n> like; they just have to deliver patches that are clean.  If they are,\n> I'll pull from their repository.  If they aren't, I won't.\n\nRepo talks a lot about automating the workflow that leads to precisely\nthat decision. They evidently want something more evolved than\nsomebody simply having a look at the code. I'm not sure what they\nwant, but I'm pretty sure it's none of the developer's business.\n\nAdrian.\n"},{"id":"128243","messageId":"90e180400911240329x93768f6t4b39e643b56e20e1@mail.gmail.com","threadId":"21684","inReplyTo":"65e170e70911231948l3b032dbeu7c99b65ce3ec97ff@mail.gmail.com","subject":"Re: Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?","fromName":"Bob Hazard","fromEmail":"linuxoflondon@googlemail.com","sentAt":"2009-11-24T11:29:33Z","receivedAt":"2009-11-24T11:29:33Z","isPatch":false,"sender":{"key":"linuxoflondon@googlemail.com","avatar":null},"body":"Git's raison d'etre was to make merging cheaper.  You are encouraged\nto make as many local branches as you want to experiment on features\n\n\"if a longer experiment that I have committed several stages of turns\nout to be a\nblind alley, I'd like to go back a few steps on main, declare\neverything after that to be a side branch that I'll probably never use\nagain, and continue on main with my next attempt. Is that possible?\"\n\n\nYes.\n\nThis google tech talk by Randal Schwartz is a little old but it might help\n\nhttp://www.youtube.com/watch?v=8dhZ9BXQgc4\n\n\n\n2009/11/24 Adrian May <adrian.alexander.may@gmail.com>:\n>> If you don't have bolt-on scripts, and you move that into the the core\n>> SCM, then you force *all* projects to use whatever workflow was\n>> decided as being the One True Way of doing things as seen by the SCM\n>> designer.  So the question is whether the SCM *should* regiment all\n>> projects into following the SCM's designers idea of the One True\n>> Workflow.\n>\n> Of course I'd want the workflow configurable by whoever controls the\n> main repository. I couldn't possibly suggest that all git projects\n> need the same workflow. The number of developers can vary by five\n> orders of magnitude - that calls for different workflow models.\n>\n>> Git's approach is to say that it will be fairly flexible about\n>> dictating workflow --- who pushs to whom; whether there is a single\n>> \"star\" repository topology, or something that is more flexible, etc.\n>> You seem to hate this flexibility, because it makes life harder until\n>> you set up these bolt-on scripts.  But that's what many of us like\n>> about git; that it doesn't force us (the project lead) into a single\n>> way of doing things.\n>\n> Leaving aside topology, I suppose we can agree that the subject\n> divides into two aspects: offering the developer some optional tools,\n> and asserting control over what gets commited to the official repo.\n> Perhaps we can also agree that the former belongs under the control of\n> the developer and the latter should be in the PM's hands. You seem to\n> have opinions about which of these two aspects is more or less\n> important, and to what extent git suffices, but I don't. I assume that\n> the project manager has his own opinions about both aspects and I'm\n> observing two big projects that independantly have augmented git's\n> features with their own scripts. Their docs talk about both aspects,\n> especially repo's, but they are entirely implemented in\n> developer-overridable scripts. So any repo functions to do with the\n> second aspect are either features that git needs to grow, or bits of\n> the git manual that the repo designer didn't read. I'd kinda like to\n> know which.\n>\n> Returning to topology, I think that also divides up similarly. The PM\n> can't forbid you and me from casually swapping diffs back and forth,\n> but he can dictate who we are supposed to submit our final candidate\n> to for review. The very existence of a PM, who controls a subset of\n> the repositories in the world, already implies a star topology, and I\n> think pretty much everybody is using distributed source control in\n> this way, at least when it comes down to *controlling* anything.\n> People may also be causally bouncing diffs around, but that's not\n> control, it's communication. I've got a one-man project on github\n> which I edit from two locations, and even on that scale I find myself\n> working star-fashion because either computer might have junk\n> experiments in progress, but I only push to github if it's meaningful\n> and tidy.\n>\n> That reminds me of a slightly different question: if a longer\n> experiment that I have committed several stages of turns out to be a\n> blind alley, I'd like to go back a few steps on main, declare\n> everything after that to be a side branch that I'll probably never use\n> again, and continue on main with my next attempt. Is that possible? I\n> know that I can just start a new branch from the before the bad\n> experiment, but if that happens a lot, the name of my current main\n> branch would be changing all the time, and I think that's bad. I\n> suspect what I want is possible, but I'm not sure how to do it.\n>\n>> As far as my wanting to impose a particular regimen on my project's\n>> developers, I've never been a big fan of the Bondage and Discpline\n>> school of software engineering.  They can use whatever workflow they\n>> like; they just have to deliver patches that are clean.  If they are,\n>> I'll pull from their repository.  If they aren't, I won't.\n>\n> Repo talks a lot about automating the workflow that leads to precisely\n> that decision. They evidently want something more evolved than\n> somebody simply having a look at the code. I'm not sure what they\n> want, but I'm pretty sure it's none of the developer's business.\n>\n> Adrian.\n>\n> --\n> Chromium Discussion mailing list: chromium-discuss@googlegroups.com\n> View archives, change email options, or unsubscribe:\n>    http://groups.google.com/group/chromium-discuss\n\n-- \nChromium Discussion mailing list: chromium-discuss@googlegroups.com \nView archives, change email options, or unsubscribe: \n    http://groups.google.com/group/chromium-discuss\n"},{"id":"128261","messageId":"alpine.LNX.2.00.0911241441520.14365@iabervon.org","threadId":"21684","inReplyTo":"65e170e70911231948l3b032dbeu7c99b65ce3ec97ff@mail.gmail.com","subject":"Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-11-24T20:45:42Z","receivedAt":"2009-11-24T20:45:42Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 24 Nov 2009, Adrian May wrote:\n\n> > If you don't have bolt-on scripts, and you move that into the the core\n> > SCM, then you force *all* projects to use whatever workflow was\n> > decided as being the One True Way of doing things as seen by the SCM\n> > designer.  So the question is whether the SCM *should* regiment all\n> > projects into following the SCM's designers idea of the One True\n> > Workflow.\n> \n> Of course I'd want the workflow configurable by whoever controls the\n> main repository. I couldn't possibly suggest that all git projects\n> need the same workflow. The number of developers can vary by five\n> orders of magnitude - that calls for different workflow models.\n> \n> > Git's approach is to say that it will be fairly flexible about\n> > dictating workflow --- who pushs to whom; whether there is a single\n> > \"star\" repository topology, or something that is more flexible, etc.\n> > You seem to hate this flexibility, because it makes life harder until\n> > you set up these bolt-on scripts.  But that's what many of us like\n> > about git; that it doesn't force us (the project lead) into a single\n> > way of doing things.\n> \n> Leaving aside topology, I suppose we can agree that the subject\n> divides into two aspects: offering the developer some optional tools,\n> and asserting control over what gets commited to the official repo.\n> Perhaps we can also agree that the former belongs under the control of\n> the developer and the latter should be in the PM's hands. You seem to\n> have opinions about which of these two aspects is more or less\n> important, and to what extent git suffices, but I don't. I assume that\n> the project manager has his own opinions about both aspects and I'm\n> observing two big projects that independantly have augmented git's\n> features with their own scripts. Their docs talk about both aspects,\n> especially repo's, but they are entirely implemented in\n> developer-overridable scripts. So any repo functions to do with the\n> second aspect are either features that git needs to grow, or bits of\n> the git manual that the repo designer didn't read. I'd kinda like to\n> know which.\n\nRepo (and gclient, which claims to be for SVN) seems to be mostly about \nthe fact that nothing really handles submodules (independant projects that \nare also parts of larger projects) well. This is a known flaw with git, \nbut it's unclear as to whether repo does better. It's probably best to let \nthem work out a set of semantics which a real-world, full-scale project is \nhappy with, and consider adopting it for native submodules when there's \nreal-world positive experience behind it.\n\nThe other main thing I see repo doing is interfacing with gerrit, where \nyour pushes get redirected, and there are a million review branches you \ncan find on a web site, and where the server for a push is different from \nthe best server for a mainline fetch. Some of this is probably worth \nhaving natively, but there's still the case of wanting to fetch a review \nbranch based on understanding stuff about gerrit. This is similar to \nwanting to get a SVN revision out of bugzilla; you really want a tool \nthat's particular to the integration of the systems you're using, not \nstuff built into your version control system. That said, if the submodule \nstuff were taken care of, Google could provide a git-review program, and \ndo everything within the \"git ...\" wrapper instead of as an outer script.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}