Re: interactive rebase results across shared histories

From: Seb <spluque@gmail.com>
Date: Feb 26, 2016, 21:12 UTC
Message-ID: <87povj41m9.fsf@gmail.com>
In-Reply-To: <CAMPXz=on8ONkzDYWEEGFqqKhRoBb9zYBqmYDBsKWagdwFRPRdA@mail.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:

>> [...]

Show 5 quoted lines

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