Re: interactive rebase results across shared histories

[Moritz Neeb <lists@moritzneeb.de>]

On 02/23/2016 06:39 PM, Seb wrote:
> On Sun, 21 Feb 2016 03:12:49 +0100,
> Moritz Neeb <lists@moritzneeb.de> wrote:
> 
>> 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:
> 
> [...]
> 
>> 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.
> 
> OK, I've followed this advice and looked at the dependency graphs in
> gitk before and after rebasing, I've managed to obtain what I was
> after.  The repository now has two branches: master and topic.  However,
> Gitk reveals a problem with a string of commits that are not part of any
> branch:
> 
> A---B---H---I                   (master)
>      \
>       C---D---E                 (loose string of commits)
>        \
>         D'---E'---F---G         (topic)
> 
> How do I remove these loose commits (C, D, E)?
>

what you might be after is "git gc". But I never used it, it was not
neccesary for me. I would let the automatic garbage collection drop my
dangling commits. It's safer - who knows when you will still want to
restore your recent "loose string of commits".

How exactly are the loose commits causing trouble?

-Moritz