Re: interactive rebase results across shared histories

[Seb <spluque@gmail.com>]

On Sun, 21 Feb 2016 14:08:44 -0500,
Eric Sunshine <sunshine@sunshineco.com> wrote:

[...]

> 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'.

Thank you for this excellent explanation.  I will look into git rebase
--onto to have both branches share the history that should be shared
after the interactive rebase.  Fortunately, this is a private repository
for now.

-- 
Seb