Git's raison d'etre was to make merging cheaper. You are encouraged to make as many local branches as you want to experiment on features "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?" Yes. This google tech talk by Randal Schwartz is a little old but it might help http://www.youtube.com/watch?v=8dhZ9BXQgc4 2009/11/24 Adrian May <adrian.alexander.may@xxxxxxxxx>: >> 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. > > -- > Chromium Discussion mailing list: chromium-discuss@xxxxxxxxxxxxxxxx > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-discuss -- 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