Re: interactive rebase results across shared histories

From

SSeb <spluque@gmail.com>

Date

Feb 22, 2016, 03:32 UTC

Message-ID

<87y4ad5sis.fsf@gmail.com>

In-Reply-To

<CAPig+cSxmWc_Guab0UoQbRMEkVLr-qhF=LCiVk10G5AdnTqnGA@mail.gmail.com>

[...]

> What you're probably missing is that you can't actually edit commits
> in Git. Instead, what you think of as "editing" actually creates a new
> commit with its own commit-ID, and the original commit still exists
> with its own commit-ID. Since Git commits are chained together by
> their commit-ID's, any commits pointing at the original commit-ID
> continue to point to that commit, and only commits rebased atop the
> new commit-ID of the "edited" commit point at it.

> In your example, you're "editing" D and E, which creates new commits
> D' and E', so your resulting graph looks like this:

>     D'---E'---A---B---C topic / *---D---E---F---G master

> So, "master" and "topic" really are not sharing D and E (or D' and
> E'). You could "fix" this to match your intuition by rebasing F...G
> onto E' (see git-rebase --onto, for instance), which would give you
> this:

>                   A---B---C topic / *---D'---E'---F---G master

> and then "master" and "topic" would really be sharing D' and E' as
> common history. (Of course, rebasing "master" or any branch may not be
> desirable if you've published it, so applicable warnings about
> rebasing apply.)

> By the way, the problem isn't restricted to when you rebase "topic"
> (as your problem description implies). You'd see the same behavior if
> you'd rebased D and E in "master" to become D' and E'. "topic" would
> still have old D and E in its history, and not D' and E'.

-- 
Seb