replacing a bad commit

replacing a bad commit

[Blu Corater]

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.

Re: replacing a bad commit

[Jakub Narebski]

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

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: replacing a bad commit

[Blu Corater]

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.

Re: replacing a bad commit

[Shawn O. Pearce]

Blu Corater <blu@daga.cl> wrote:
> I've got confused by the wording of the git-rebase man page. It says:
> 
>        <upstream>
>           Upstream branch to compare against

Hmm.  Yes, that manpage can be somewhat confusing.
 
> 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.

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.

-- 
Shawn.

Re: replacing a bad commit

[Blu Corater]

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

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

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

Thanks.

-- 
Blu.

Re: replacing a bad commit

[Jakub Narebski]

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

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

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? ;-)
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: replacing a bad commit

[Blu Corater]

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

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

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.

Re: replacing a bad commit

[Shawn O. Pearce]

Blu Corater <blu@daga.cl> wrote:
> Let me learn the list conventions on sending patches and I will send
> something.

Its covered in Documentation/SubmittingPatches.

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

-- 
Shawn.