>> good. But it has its usual problems of forcing everyone to religiously >> publish _AND_ keep rebasing on main branch every so often. Also my >> major problem is that we discover conflicts only _after_ a developer >> tries to rebase his work, typically (by design) after he has fully >> coded and tested a feature. > > What sort of time frame are you talking about? How long are your > sprints, or however you partition your work. > > I can't help but feel the problem should be solved elsewhere. Do you > have daily scrums? Everyone should know, roughly, what everyone is > doing. If you are using 2-3 week sprints (or however you partition > the time) and everyone is roughly aware of what everyone else around > them is doing, there shouldn't really be so much of a problem. Well as i said in informal way we do shout out loud (managers: read as 'daily meetings') when we want to make changes that might conflict with some one else and i have been blessed with a rather good dev team who can spot this right, and it works well for now for these short sprints. However see below for my itch. >> The current way to get around this is shouting aloud before you start >> working on a new feature/file/section. > > How do you allocate the features in the first place? At the start of > a sprint? If so, it should be the person in charge of that that > should see if there are going to be conflicts. If you don't have > sprints, then how do you divide up tasks? Yes as i said this generally works. But and this is a big BUT, this essentially makes the developer the point of failure (in reporting the conflict). And in my view (exactly contrary to yours) the problem should be solved else where. Also we are working on many porting projects which need changes to the same file but not essentially logically conflicting, which if, everyone is aware of at the moment the change is made (commited?) is trivial to resolve. However when you have 100 such changes at the end of a sprint thats a problem. Yes git makes it extremely easy to merge i can't even begin to think about the current style of development in svn deployment. And we can resolve those conflicts fairly easy. Its just that I have to depend then on individual's ability to persist through what seems like million merge conflicts. And no its not avoidable, we _have_ to do those conflicting changes in order to keep the pace of development. Its just about reporting them sanely and quickly which is ok to be done manually, but it pains me that the info can be available with some tool as well with obvious benifits of automation. So the idea is sort of local linux-next style automation for small teams. BAIN > John -- 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