> 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. Returning to topology, I think that also divides up similarly. The PM can't forbid you and me from casually swapping diffs back and forth, but he can dictate who we are supposed to submit our final candidate to for review. The very existence of a PM, who controls a subset of the repositories in the world, already implies a star topology, and I think pretty much everybody is using distributed source control in this way, at least when it comes down to *controlling* anything. People may also be causally bouncing diffs around, but that's not control, it's communication. I've got a one-man project on github which I edit from two locations, and even on that scale I find myself working star-fashion because either computer might have junk experiments in progress, but I only push to github if it's meaningful and tidy. That reminds me of a slightly different question: if a longer experiment that I have committed several stages of turns out to be a blind alley, I'd like to go back a few steps on main, declare everything after that to be a side branch that I'll probably never use again, and continue on main with my next attempt. Is that possible? I know that I can just start a new branch from the before the bad experiment, but if that happens a lot, the name of my current main branch would be changing all the time, and I think that's bad. I suspect what I want is possible, but I'm not sure how to do it. > As far as my wanting to impose a particular regimen on my project's > developers, I've never been a big fan of the Bondage and Discpline > school of software engineering. They can use whatever workflow they > like; they just have to deliver patches that are clean. If they are, > I'll pull from their repository. If they aren't, I won't. Repo talks a lot about automating the workflow that leads to precisely that decision. They evidently want something more evolved than somebody simply having a look at the code. I'm not sure what they want, but I'm pretty sure it's none of the developer's business. Adrian. -- 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