Re: interactive rebase results across shared histories

[Kevin Daudt <me@ikke.info>]

On Tue, Feb 23, 2016 at 11:57:06PM +0100, Moritz Neeb wrote:
> 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?
> 

Right, you should normally not care about these commits. In any case,
the reflog is still keeping a reference to these commits, and objects
not older then 14 days are also kept.

But git is regularly running its gc to clean up older objects, and they
will not be shared when pushing.