Re: [PATCH] rebase --merge: fix for rebasing more than 7 commits.

[Eric Wong <normalperson@yhbt.net>]

Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
> 
> >  * I wanted to raise my confidence level in the new rebase --merge
> >    code, so I did a little exercise which resulted in finding this
> >    buglet.
> >...
> >    So the exercise went like this:
> >...
> >   With this fix, the above works beautifully.  I am reasonably
> >   happy with this shiny new toy.  Good job, Eric! and thanks.

:)  Thanks for the extra QA and fix.

> By the way, I do not quite understand the reasoning behind not
> moving the head being rebased until the finalization phase.

That's because my original patch that only used git-merge, which didn't
let me manually commit with all the information from a previous commit.

> Also I think --skip would be straightforward.  What you look at
> in call_merge() is the current HEAD, the commit being rebased
> and its direct parent (actually what you are interested in are
> trees of these commits and not ancestry chains among them -- if
> we can tell git-merge-recursive not to try its own "recursive"
> merge base finding but just use what we give it as the base, I
> could sleep better.  I think the current code could misbehave in
> funnier ancestry graph if we allow it to pick merge base on its
> own), so skipping is just a matter of, eh, skipping the commit.

Another consequence of relying on plain git-merge in my original
patch.  --skip should be very doable now that we can specify
the correct base.  I'll look into it more when I'm more awake.

-- 
Eric Wong