Re: interactive rebase results across shared histories

From: Moritz Neeb <lists@moritzneeb.de>
Date: Feb 21, 2016, 02:12 UTC
Message-ID: <56C91D21.90306@moritzneeb.de>
In-Reply-To: <87io1j6laz.fsf@gmail.com>

Hi Seb,

On 02/20/2016 11:58 PM, Seb wrote:

Show 8 quoted lines

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