Hi,
Junio C Hamano wrote:
> Stephan Beyer <s-beyer@xxxxxxx> writes:
>
> ... Based on the discussion thread, here is a rewrite of the log message.
>
> > When "rebase -i -p" tries to preserve merges of unrelated branches, it
> > lost some parents:
> >
> > - When you have more than two parents, the commit in the new history
> > ends up with fewer than expected number of parents and this breakage
> > goes unnoticed;
> >
> > - When you are rebasing a merge with two parents and one is lost, the
> > command tries to cherry-pick the original merge commit, and the command
> > fails.
> >
> > Signed-off-by: Stephan Beyer <s-beyer@xxxxxxx>
Ok, big thanks :)
> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > index a35212d..0df7640 100755
> > --- a/git-rebase--interactive.sh
> > +++ b/git-rebase--interactive.sh
> > @@ -174,6 +174,8 @@ pick_one_preserving_merges () {
> > new_parents="$new_parents $new_p"
> > ;;
> > esac
> > + else
> > + new_parents="$new_parents $p"
> > fi
> > done
>
> Reading the surrounding code, it makes me wonder if you also need to futz
> with variables like $preserve and $fast_forward.
No, I would not see a reason for that.
Regards,
Stephan
--
Stephan Beyer <s-beyer@xxxxxxx>, PGP 0x6EDDD207FCC5040F
--
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
