Re: What I want rebase to do
- From
Johannes Sixt <j.sixt@viscovery.net>
- Date
- Mar 7, 2013, 10:08 UTC
- Message-ID
- <51386732.1020708@viscovery.net>
- In-Reply-To
- <87r4jra942.fsf@pctrast.inf.ethz.ch>
Am 3/7/2013 9:48, schrieb Thomas Rast:
Show 27 quoted lines
> 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 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