Re: Rebase, please help

On Wednesday 2007 April 11 08:38, Junio C Hamano wrote:

This is interesting and brings to mind a difficult I've had. I had problems with rebase when rebasing chains with a file that was self-similar. Indulge me for a while with this example (forgive the C++, but that's where I had this problem):

class A : public C
{
   // ...

   int someVirtualOverride(n) { return ArrayA[n]; }

   // ...
}

class B : public C
{
   // ...

   int someVirtualOverride(n) { return ArrayB[n]; }

   // ...
}

One patch changed "ArrayX[n]" to "Array.at(n)" and another inserted more similar classes around these two.

When I was rebasing, some strange things happened (without any conflict warnings):

class D : public C
{
   int someVirtualOverride(n) { return ArrayA.at(n); }
}

class A : public C
{
   int someVirtualOverride(n) { return ArrayB.at(n); }
}

class B : public C
{
   int someVirtualOverride(n) { return ArrayB[n]; }
}

Notice that the arrays don't match up with the classes. By some crazy coincidence and the strong similarity between localities within the file, the patch successfully applied in the wrong place. The fix was easy enough to do manually, but it needed a bit of untangling as this was in a longish chain of revisions that I was rebasing.

I didn't mind much, and hence didn't report it as a bug as I guessed it was to do with git-rebase using git-am. The annoying part was actually that there was no conflict warning and hence the rest of the chain applied, making it all the more difficult to untangle.

My question then is this: given that I don't care about speed of rebase, is it safe to permanently use --merge with rebase, and would that have caught the error in the above case?

Andy