[email protected] (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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
