On Fri, May 21, 2010 at 00:09, Andreas Schwab <schwab@xxxxxxxxxxxxxx> wrote:
> Antriksh Pany <antriksh.pany@xxxxxxxxx> writes:
>
>> Instead of (what I initially expected):
>>
>> A--------o--------o--------o--------o(old B)--------o--------o--------o(old C)
>>
>> A2--------o--------o--------o--------B--------o--------o--------C
>>
>>
>> So what I am missing here? Aren't the new commits B~1, B~2, B~3
>> identical to C~4, C~5, C~6 (respectively) in all ways so as to have
>> gotten them the same SHA1 and hence appear as what I expected them to
>> appear?
>
> No, they have a different commit time, which is also part of the hash.
Indeed.
To avoid this, you have to:
- rebase B on top of A2 first,
git rebase --onto A2 A B
- rebase of C on top of the new B.
git rebase --onto B B_old C
("git rebase --onto B A C" should work too, as usually git is
smart enough to see
that A-B_old is already applied. Use "git rebase --skip" if it isn't)
If A is an ancestor of A2, you can simplify to:
git rebase A2 B
git rebase B C
(Disclaimer: the examples without --onto I use almost daily, the ones
with I don't)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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