> > > In the future, is there a better way for two developers to work in the same > > > back-and-forth fashion (code ping pong!) without leading to *heavily* merged > > > histories that are unpossible to untangle? > > > > Discipline. Keep developers focused on their topic. Merge only after a > > topic is completed. Do not give in to "oh, *your* feature is cool, *I* > > want to have it now, so I merge it". > > I think that's easier said than done, with backend work I'm able to clearly > define topics, whereas the front-end developers (as it is in this case) > typically overlap ever so slightly in their work > If two developers are working together, then set them up so that each has a public and private repo. The rule should be: 1. before publishing, A fetches from B to ensure that A has B's latest public tip 2. A confirms that B's tip includes A's public tip 3. A rebases own private changes (between A public and A private) onto B's public tip 4. A pushes her rebased private tip to her own public repo 5. B then repeats the cycle with the roles reversed. This will work provided that B doesn't republish after 2 and before 4, so does require that A and B talk to each other before performing step 4. jon. -- 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