Re: Rebasing with merges and conflict resolutions

[Johannes Sixt <j.sixt@viscovery.net>]

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