Re: replacing a bad commit

[Blu Corater <blu@daga.cl>]

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.