Re: interactive rebase results across shared histories

[Seb <spluque@gmail.com>]

On Fri, 26 Feb 2016 23:38:38 +1100,
David <bouncingcats@gmail.com> wrote:

> On 24 February 2016 at 10:05, Seb <spluque@gmail.com> wrote:
>> On Tue, 23 Feb 2016 23:57:06 +0100,
>> Moritz Neeb <lists@moritzneeb.de> wrote:

>> [...]

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

>> Sure enough, these dangling commits were removed automatically
>> without any intervention.  All is good.

> This discussion could end there without problem. But if you want to
> understand a little more thoroughly, read on ...

Thanks David, I appreciate the insight.  Indeed, I've learnt a lot over
the last few days with help in this thread as I confronted a lurking
problem after many years neglecting it.  Briefly, long ago I was
developing a project in RCS, then on CVS and SVN, until some years ago I
imported it into git via cvs2svn.  I had turned a blind eye to a bit of
mess up to the very early releases, likely due to my inexperience but
also differences between VCS.

After cleaning up all the mess, I've ended up with a long master branch,
and a series of earlier commits that are not reachable from master.
Fortunately, the tags have kept them alive. This is the scenario
simplified:

A---C---D(tag2)                 loose commits (not on any branch)
 \
  B(tag1)

E---F---G---H---*               (master)

I could put the "loose" (but tagged) commits on a branch at "tag2", but
I hate that "tag1" shows as a twig there...  It would be nice to have
all the history reachable from master.  So two questions I'm working on
right now: 1) how to bring "tag1" into the "tag2" chain of commits, and
then 2) how to tie it all together into master so that it reads
linearly.

-- 
Seb