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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <junkio@xxxxxxx> 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.

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

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.


-
: 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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]