The longer I use Git, the more things I find to love. Of course when I say "love", I don't mean the fanboy kind of love, but the feeling of satisfaction and happiness which good tools give the proud professional :-) I just recently realized how easy it is to apply an arbitrary commit on top of another one, without treating it as a patch. Since all high-level Git commands work with patches and diffs, one sometimes forgets that internally Git doesn't use patches, but simply stores the state of the tree as is at any point. So, to put commit-a on top of commit-b, I simply do: git-checkout commit-a git-read-tree -u -a commit-b Again, this doesn't apply commit-b as a patch on top of commit-a; it copies the exact state of the tree in commit-b. Why is this necessary? Sometimes there can be a very messy path from commit-a to commit-b, while all we want to record in the official history is just the two commits. After reading the Git user manual, the first i...