On 02/23/2016 06:39 PM, Seb wrote: > On Sun, 21 Feb 2016 03:12:49 +0100, > Moritz Neeb <lists@xxxxxxxxxxxxx> 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? -Moritz -- 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