Re: Rebasing with merges and conflict resolutions

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