Subject: Re: interactive rebase results across shared histories

From: Moritz Neeb <[email-masked]>
Date: Sun, 21 Feb 2016 03:12:49 +0100

Hi Seb,

On 02/20/2016 11:58 PM, Seb wrote:
> Hello,
> 
> I've recently learnt how to consolidate and clean up the master branch's
> commit history.  I've squashed/fixuped many commits thinking these would
> propagate to the children branches with whom it shares the earlier parts
> of the its history.  However, this is not the case; switching to the
> child branch still shows the non-rebased (dirty) commit history from
> master.  Am I misunderstanding something with this?

I am not sure what you meand by "child branch". If I understand
corretly, you have something like:

            A---B---C topic
           /
      D---E---F---G master

then you merge the topic:

            A---B---C topic
           /         \
      D---E---F---G---H master

and then you do something like "git rebase -i E" to linearize history
and maybe squash some commits, to result in something like:

      D---E---F---G---AB'---C' master

Where AB' is a squashed commit containing the changes from A and B.

Now, your misunderstanding may be in the fact of "what happened to the
topic branch?". Because looking at the whole graph, you have something
like this:

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

where it is important to note, that the topic still points to C. Which
is totally correct, because you did not say anything about topic after
the merge. If you wanted to continue working on the topic branch, then
maybe a non-interactive rebasing, like described in the rebase manpage
would be something you might want to do before rebasing. E.g., from the
start doing "git rebase master topic" leads to:

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

and then you could squash your commits as you like with "git rebase -i G":

	      AB'--C' topic
             /
D---E---F---G master

and maybe fast-forward merging master with "git merge master", then you
have both branches pointing to C':

    D---E---F---G---AB'--C' topic,master

The same could've been reached in one step via "git rebase -i master topic".

Maybe, to get a better understanding, you could use visualization tool
like "tig" or "gitk" to observe what happens to your commits (hashes)
and branches (labels) and just play around with some of these operations.