Am 3/7/2013 9:48, schrieb Thomas Rast: > wor...@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 proposed this long ago, but by modifying preserve-merges rather than with a new option (--first-parent): http://thread.gmane.org/gmane.comp.version-control.git/198125 It works very well. I'm using it frequently in the field. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
