Hi Ian, Ian Hobson wrote: > O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O Master > | \ > | O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O London > | > | \ O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O Birmingham > | > | \ O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O Glasgow > | > | \ O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O Sheffield > | > \ O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O Cardiff > > All the rebase master's are taking an age (and involve many > conflicts). They are taking linger than the development. > > So this solution is NOT working for maintaining parallel versions. I like the train track guide. My suggestion would be to take a step back and consider what your requirements are. ‘git rebase’ was designed to support a workflow in which individuals are responsible for short patch series (up to 10 patches, say) that have not been reviewed and accepted yet. To save reviewers the trouble of placing themselves in a mindset of the past, the patch submitter occasionally “refreshes” the patches to fit an appropriately modern codebase. With this comes a downside: if the patch submitter immediately sends the patches after doing this (bad submitter!), they are sending untested code. Furthermore, they make it very hard for /other people/ to develop code on top of their constantly shifting code. So when a patch series grows long enough that a simple read-through would be unfeasible anyway, rebasing can be a very bad idea. You may also be interested in http://thread.gmane.org/gmane.comp.video.dri.devel/34739/focus=34744 Good luck, Jonathan -- 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