Re: replacing a bad commit
- From
- Blu Corater <blu@daga.cl>
- Date
- Feb 5, 2007, 19:53 UTC
- Message-ID
- <20070205195332.GW14499@daga.cl>
- In-Reply-To
- <eq7mf0$lb0$1@sea.gmane.org>
On Mon, Feb 05, 2007 at 05:38:18PM +0100, Jakub Narebski wrote:
Show 29 quoted lines
> 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 againstWhich 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.