Need to change old commit (and regenerate tree)

Need to change old commit (and regenerate tree)

[Antriksh Pany]

Hi all

My question is this: I have two branches (say B and C) where one is
reachable from the other (say B is ancestor of C), and if they are
separately rebased about/onto the same point, why do B and C become
non-overlapping branches?

Let me explain with an example.

Say I have the following commit line:

A--------o--------o--------o--------B--------o--------o--------C

A, B and C are branches (so that B is reachable from C, and A is
reachable from B). [For ease, I am drawing the branches at the same
level since there are no real diverging branches here.]

I then realise that I want to change the commit A and have both B and
C rebased on this changed commit.

Now when I do a
  $ git rebase --onto A2 A C

This results in two parallel trees like these:

A--------o--------o--------o--------B--------o--------o--------o(old C)

A2--------o--------o--------o--------o--------o--------o--------C

Now I go about rebasing B. I can of course 'reset' B to C~3. But
alternatively, if I decide to do a rebase:
  $ git rebase --onto A2 A B

I will end up getting

A--------o--------o--------o--------o(old B)--------o--------o--------o(old C)

A2--------o--------o--------o--------o--------o--------o--------C
   \
     ` -----o--------o--------o--------B

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?

I have taken a simple example here. In reality, I wanted to change a
not so new commit (on the main line), and there were many branches
diverging out from the main line after the (bad) commit. I initially
thought I could just write a simple script that would rebase all
branches that have the bad commit as an ancestor, and the new tree
would be a mirror image of the original. But that was not to be! There
is also the problem of resetting tags (and possible notes).


I am sorry if this has already been discussed, please point me to the
right resource if so.

My git version:
  $ git --version
  git version 1.7.0.5

Thanks
Antriksh Pany

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

[Andreas Schwab]

Antriksh Pany <antriksh.pany@gmail.com> 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.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Jon Seymour]

On Fri, May 21, 2010 at 8:09 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Antriksh Pany <antriksh.pany@gmail.com> 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.
>

Of course, even if the commit time was forged to be the same, the
parent of B~3 is different to the parent of C~6 and since the parent
is also contributes bits to the respective hashes, B~3 will
necessarily (unlikely hash collisions excepted!) have a different hash
to C~6

jon.

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

[Antriksh Pany]

Hi Jon

I guess the parent of both B~3 as well as C~6 is A2. So if, as you
say, the time can be made
identical, they should yield the same SHA1 IMHO.

On Fri, May 21, 2010 at 12:05 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
> On Fri, May 21, 2010 at 8:09 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Antriksh Pany <antriksh.pany@gmail.com> 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.
>>
>
> Of course, even if the commit time was forged to be the same, the
> parent of B~3 is different to the parent of C~6 and since the parent
> is also contributes bits to the respective hashes, B~3 will
> necessarily (unlikely hash collisions excepted!) have a different hash
> to C~6
>
> jon.
>

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

[Geert Uytterhoeven]

On Fri, May 21, 2010 at 00:09, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Antriksh Pany <antriksh.pany@gmail.com> 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

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

[Antriksh Pany]

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
<geert@linux-m68k.org> wrote:
> On Fri, May 21, 2010 at 00:09, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Antriksh Pany <antriksh.pany@gmail.com> 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
>