On Fri, 26 Feb 2016 23:38:38 +1100, David <bouncingcats@xxxxxxxxx> wrote: > On 24 February 2016 at 10:05, Seb <spluque@xxxxxxxxx> wrote: >> On Tue, 23 Feb 2016 23:57:06 +0100, >> Moritz Neeb <lists@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html