On Tue, 24 Nov 2009, Adrian May wrote: > > If you don't have bolt-on scripts, and you move that into the the core > > SCM, then you force *all* projects to use whatever workflow was > > decided as being the One True Way of doing things as seen by the SCM > > designer. So the question is whether the SCM *should* regiment all > > projects into following the SCM's designers idea of the One True > > Workflow. > > Of course I'd want the workflow configurable by whoever controls the > main repository. I couldn't possibly suggest that all git projects > need the same workflow. The number of developers can vary by five > orders of magnitude - that calls for different workflow models. > > > Git's approach is to say that it will be fairly flexible about > > dictating workflow --- who pushs to whom; whether there is a single > > "star" repository topology, or something that is more flexible, etc. > > You seem to hate this flexibility, because it makes life harder until > > you set up these bolt-on scripts. But that's what many of us like > > about git; that it doesn't force us (the project lead) into a single > > way of doing things. > > Leaving aside topology, I suppose we can agree that the subject > divides into two aspects: offering the developer some optional tools, > and asserting control over what gets commited to the official repo. > Perhaps we can also agree that the former belongs under the control of > the developer and the latter should be in the PM's hands. You seem to > have opinions about which of these two aspects is more or less > important, and to what extent git suffices, but I don't. I assume that > the project manager has his own opinions about both aspects and I'm > observing two big projects that independantly have augmented git's > features with their own scripts. Their docs talk about both aspects, > especially repo's, but they are entirely implemented in > developer-overridable scripts. So any repo functions to do with the > second aspect are either features that git needs to grow, or bits of > the git manual that the repo designer didn't read. I'd kinda like to > know which. Repo (and gclient, which claims to be for SVN) seems to be mostly about the fact that nothing really handles submodules (independant projects that are also parts of larger projects) well. This is a known flaw with git, but it's unclear as to whether repo does better. It's probably best to let them work out a set of semantics which a real-world, full-scale project is happy with, and consider adopting it for native submodules when there's real-world positive experience behind it. The other main thing I see repo doing is interfacing with gerrit, where your pushes get redirected, and there are a million review branches you can find on a web site, and where the server for a push is different from the best server for a mainline fetch. Some of this is probably worth having natively, but there's still the case of wanting to fetch a review branch based on understanding stuff about gerrit. This is similar to wanting to get a SVN revision out of bugzilla; you really want a tool that's particular to the integration of the systems you're using, not stuff built into your version control system. That said, if the submodule stuff were taken care of, Google could provide a git-review program, and do everything within the "git ..." wrapper instead of as an outer script. -Daniel *This .sig left intentionally blank* -- 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