Re: Need to change old commit (and regenerate tree)

Thanks a lot.

I guess it is then not so straightforward to regenerate trees with
their relative structure
intact when an old commit changes. I was initially of the opinion that
it would be a trivial
rebasing of all branches from which the commit was reachable.
Apparently, not so.

On Fri, May 21, 2010 at 6:31 AM, Geert Uytterhoeven
[off-list ref] wrote:

On Fri, May 21, 2010 at 00:09, Andreas Schwab [off-list ref] wrote:

quoted

Antriksh Pany [off-list ref] writes:

quoted

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@linux-m68k.org

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