On Wednesday 2007 April 11 08:38, Junio C Hamano wrote:
> I find that the regular rebase without --merge is faster (at
> least it feels to me that it is, and I kind of understand why;
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
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html