Re: What I want rebase to do

From: Thomas Rast <trast@student.ethz.ch>
Date: Mar 7, 2013, 08:48 UTC
Message-ID: <87r4jra942.fsf@pctrast.inf.ethz.ch>
In-Reply-To: <201303061855.r26ItKtM018797@freeze.ariadne.com>

worley@alum.mit.edu (Dale R. Worley) writes: [...snip...]

Isn't that just a very long-winded way of restating what Junio said earlier:

> > It was suggested to make it apply the first-parent diff and record
> > the result, I think.  If that were an acceptable approach (I didn't
> > think about it through myself, though), that would automatically
> > cover the evil-merge case as well.

You can fake that with something like

git rev-list --first-parent --reverse RANGE_TO_REBASE |
while read rev; do
    if git rev-parse $rev^2 >/dev/null 2>&1; then
        git cherry-pick -n -m1 $rev
        git rev-parse $rev^2 >.git/MERGE_HEAD
        git commit -C$rev
    else
        git cherry-pick $rev
    fi
done

Only tested very lightly. Dealing with octopii, conflicts and actually preserving the commit's attributes is left as an exercise to the reader[1].

I still think that the _right_ solution is first redoing the merge on its original parents and then seeing how the actual merge differs from that. --preserve-merges has bigger issues though, like Junio said.

Perhaps a new option to git-rebase could trigger the above behavior for merges, who knows. (It could be called --first-parent.)

[1] If you don't get the sarcasm: that would amount to reinventing large parts of git-rebase.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch