On Sun, 21 Feb 2016 14:08:44 -0500, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html