Please don't set Mail-Followup-To on this list. Am 3/26/2010 4:11, schrieb R. Tyler Ballance: > Two contributors worked in tandem on a particular project, constantly merging > back and forth between each other creating a history of 118 commits total with > 37 of them being merge commits, 7 of those merge commits having conflict > resolutions involved. > > I would /like/ to rebase those into a more linear revision history, but I > can't seem to find any set of commands that doesn't have me: > a) Manually re-doing every conflict resolution and merge (git rebase -p master) > b) Drastically diverging from the original topic branch and entering some > sort of mergeless hell (git rebase master) I'm afraid you can't avoid the merge conflict resolutions. But you can let you help by git-rerere. Look into the script rerere-train.sh that lets you prime your rerere database. http://repo.or.cz/w/alt-git.git/blob_plain/master:/contrib/rerere-train.sh > Is it even possible to straighten this out without a massive rework of these > commits? I would sort the commits into topics and then repeatedly rebase -i the history involved onto the same commit, each time removing those commits that do not belong to the topic. That is, you get a forest of topics sprouting from the same commit. Finally, merge the topics back together. IOW, I wouldn't aim at a completely linear history, at least not at the first try. > 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". -- Hannes -- 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