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 ... First, for basic git use, please stop being concerned about when or whether dangling commits are removed or not. For basic git use, it is unimportant (except for advanced use like disaster recovery). By default, git waits a while (couple of weeks I think?) and then removes dangling commits silently. Why remove them? Because dangling commits are commits that git has been instructed to forget about and discard, because no reference (like a branch or tag) points to them. And because they are unimportant, gitk chooses not to show them; whenever you refresh or restart gitk, it won't show any dangling commits. Why does git wait before discarding them entirely? Because advanced users might want to do something clever with them. So your dangling commits (after rebase) are probably not removed for a couple of weeks. If you were to somehow recreate a reference to them, then gitk will show them again. But otherwise it treats them as unworthy of being shown. So how did you ever see the dangling commits? I think it is because gitk was aware of them because it had a reference to them before the rebase. So if you keep gitk open it still shows them afterwards even though the reference is gone. And if I recall correctly, if you refresh or restart gitk, they will disappear from its display. -- 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