On Mon, Feb 05, 2007 at 05:38:18PM +0100, Jakub Narebski wrote:
> Blu Corater wrote:
>
> > Here is the situation. Upstream realeses tarballs once in a while. I
> > maintain local modifications. Every time upstream releases a tarball, I
> > fast forward the 'upstream' branch, and merge into 'local' branch. My
> > tree, currently, looks somewhat like this:
> >
> > o---o---o <--topic2
> > |
> > | o---o---o <--topic1
> > | /
> > o---o---C---A---o---o <--local
> > / / /
> > / / /
> > o---o---o---B <--upstream
> >
> > Problem is, B should have been merged into 'local', at A, but I just
> > realized it wasn't (probably due to my own stupidity).
> >
> > I need to correct A, i.e. merge with B, but keeping the branches already
> > in flux, and propagating the changes due to the merge to them. In short,
> > replace A with a properly merged A'.
> >
> > I tried branching from C and merging with B, then rebasing topic branches,
> > but then I am not sure how to rebase 'local'to eliminate A.
>
> Try using
>
> $ git rebase --onto A' A local
Thanks a lot, that did it.
I've got confused by the wording of the git-rebase man page. It says:
<upstream>
Upstream branch to compare against
Which suggests to me that <upstream> must be a branch tip, and not a
random commit, as seems to be the case (well, not random, but reachable
from <branch> if I understand well). Also, the man page doesn't give any
example of rebasing using a random commit as <upstream>, they all use
branch tips which reinforced my wrong assumption.
--
Blu.
-
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