You might find this post from a few weeks back interesting:
http://permalink.gmane.org/gmane.comp.version-control.git/140510
Unfortunately, I haven't had time to reproduce a robust implementation
of the ideas, but I have exercised the algorithm manually a few times
and it works quite well.
The basic idea is that you split the merge history into segments
(where a segment is a single linear series of commits). Then starting
from the oldest you rewrite:
A----B---M
\---C---/
as:
A---B---e---C'---e'---M'
where e is a compensation that allows e to be automatically rebased
onto B without merge conflicts and e' restores the tree to the point
it was an M so that tree(M) and tree(M') are identical. See the
original post for working out how to construct e and e'. The basic
idea is you find the confllcts that would result if you attempted
rebase C on B, then reset part of the tree in such a way that the
conflicts are removed. e' then is the patch that restores tree(C') to
tree(M)
You have to realise that the trees between e and e' will be
inconsistent because part of the tree is shifted back in time in order
to allow the C to rebase cleanly.
Once the history is linearised in this way, it is often (but not
always) possible to reorder and then squash the commits in e --- C'
--- e' such away that the consistency of the tree in this region is
restored.
if you repeat this algorithm recursively for each merge in the merge
history you can flatten the entire merge history out into a linear
series of commits. This can be complete and automatic, alhough to
obtain completeness you do lose consistency at certain well-delimited
points in the history. Consistency can be restored, if required, by
manually rebasing the linearised history in a single pass at the end.
I do intend to commit the algorithm to code at some point, but haven't
had a chance to do so yet. See ( http://github.com/jonseymour/hammer)
for a readme that also describes the idea in more detail
jon.
On Fri, Mar 26, 2010 at 2:11 PM, R. Tyler Ballance <tyler@xxxxxxxxxxxxx> wrote:
> I am trying to use rebase to straighten out a couple topic branches' histories
> and running into nothing but troubles and I'm wondering if:
> a) I'm doing it wrong (highly likely)
> b) what I want is not possible
> c) banana!
>
> 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)
>
>
> Is it even possible to straighten this out without a massive rework of these
> commits?
>
> 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?
>
>
> Halp!
>
>
> Cheers,
> -R. Tyler Ballance
> --------------------------------------
> Jabber: rtyler@xxxxxxxxxx
> GitHub: http://github.com/rtyler
> Twitter: http://twitter.com/agentdero
> Blog: http://unethicalblogger.com
>
>
--
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