From: Antriksh Pany Date: Fri, 21 May 2010 21:46:29 GMT Subject: Re: Need to change old commit (and regenerate tree) Message-ID: In-Reply-To: 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 wrote: > On Fri, May 21, 2010 at 00:09, Andreas Schwab wrote: >> Antriksh Pany 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@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 >