Thanks!

Now I see that it makes sense. I didn’t take it into account. In my case stuff that I tried to insert in K depended on B and it had nothing to do with newer commits.

Thank you for clarifying it!

Thank you, lyzkov, for your suggestion!

It is true that some times this approach just works! Especially when you’d like to add a new file in the past or change a couple of lines somewhere else.

The problem is that we usually add staff as the time advances. If I perform another commit (K) at the head of the branch, I will also have the lines added at the previous commits (C, D, E, F) in it. When I’ll try to re-position it in the past, there will be too many conflicts because of the additions in [C, D, E, F] that will appear at their place before actually committed!

git commit -m K
git rebase -i B

and then change commit order on the list.

Thank you very much for your points. APT is really a very useful tool with lots of features and functions but, unfortunately, with only adequate documentation. So, I never feel confident with its functions except from the very basics. Yet, I find myself using more and more everyday the command-line tools to administer my systems, rather than the great Synaptic! Tips like yours bring more confidence to people like me.

Another very handy command is:

apt-get autoremove – which removes packages that were installed with others, but which you no longer require. I have never encountered a problem in doing this YMMV of course.

And worth remembering “purge” to remove applications AND configuration data, otherwise you end up with loads of orphaned configuration files, e.g. :

apt-get purge packagename (instead of apt-get remove packagename).