replacing a bad commit

Hello,

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.

Thanks in advance for any help.

Blu Corater wrote:

Try using

  $ git rebase --onto A' A local

On Mon, Feb 05, 2007 at 05:38:18PM +0100, Jakub Narebski wrote:

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 Corater <blu@daga.cl> wrote:

Hmm.  Yes, that manpage can be somewhat confusing.
 

The faster you abandon the idea of branch tip as argument, the faster you will pickup the more advanced operations in Git.

Anytime we talk about a branch as input to a command, it can really be any commit. And anytime we talk about a commit or an object, it can be expressed by using any of the operators discussed in git-rev-parse's man page, which would include using a branch name or an abbreviated (or full) SHA-1.

There are a limited number of commands which expect a branch name (and only a branch name), as they modify that branch to contain a new value. Examples of these are relatively rare, but include:

  git-branch: the first argument is the name of the branch to create.
  git-checkout -b: again, the name of the branch to create.
  git-fetch: it can be asked to update local tracking branches.

On Mon, Feb 05, 2007 at 03:02:36PM -0500, Shawn O. Pearce wrote:

[...]

[...]

Indeed. Changing that piece of mindframe makes git look a lot more powerful than it already was in my mind.

Thanks.

Blu Corater wrote:

Well, I think that two examples of using --onto should make it clear enough (especially second one), and both are quite similar to your situation I think.

But I agree that git-rebase(1) needs clarification. Do you volunteer? ;-)

On Mon, Feb 05, 2007 at 09:38:47PM +0100, Jakub Narebski wrote:

[...]

[...]

In fact I was mentally preparing a patch when Shawn got ahead of me :)

Let me learn the list conventions on sending patches and I will send something.

Blu Corater <blu@daga.cl> wrote:

Its covered in Documentation/SubmittingPatches.

Any patches to improve Git are definately welcome.  Please help.  ;-)