http://computerroriginaliascience.blogspot.com/2007/08/how-to-evaluate-dvcs.html

git also pays a performance penalty for digging up copy and rename information, which is why you need flags like –find-copies-harder etc.

Anyone who does business as a partner with Microsoft should know that first and ensure that they have adequate legal safeguards.

Which of Microsoft’s joint business ventures with other companies did not leave Microsoft as the sole beneficiary of that arrangement?

Microsoft may want to tie others to a standard and thus be free to innovate and to create new ad hoc standards using their monopoly power.

Today, IT workers spend more of their effort using Microsoft’s software than creating new applications themselves. The overhead of using such tools saps the workforce. We were far more productive using less innovation some years ago.

So, historical tampering would result in what comes out of bzr not being the same as what went in. And people who copied the tampered repository would never know.

Which one is “lossless”, again?

What git actually stores is the content of the files; it stores them in a file named as the hash of the contents – let’s pretend that hash is 12345ABCDEF. Git then keeps a list of hashes against filenames; so:

12345ABCDEF somefile.c

Now, let’s say you rename that file, from one commit to the next; git will store the new list as

12345ABCDEF newname.c

Notice that the hash hasn’t changed. So, when you compare these two lists, it’s really easy to see that somefile.c was renamed to newname.c, because the hash is common to both. Similarly for copies:

12345ABCDEF somefile.c
12345ABCDEF copy.c

Comparing this list with the original one, it’s easy to see that somefile.c hasn’t changed, but copy.c has been introduced and is a copy of somefile.c.

See? Git didn’t need to record the rename explicitly – it’s inherently available in what it does store.

What’s even better is that you get the copy free, because it’s got the same content, this list just references the same content twice, and on checkout git reads the same source object twice.

As it happens, git is even cleverer than I’ve described above and can make educated guesses about copies and renames that were changed during the revisions.

What’s really great about this, is that git figures it out on its own. So you don’t need special commands for copy, move, mkdir, rm, etc. Git knows what you’ve done because you did it, not because you told it you did it.

Begin fair, there are currently a few UI issues with git erring on the side of speed by default, and not doing these detections as it parses history. However, they aren’t particularly expensive operations and so if you wish (as I do), you can make git always detect these copies and renames. However that is a user interface issue, and should not be used to say that git doesn’t track renames. Who cares that it doesn’t track them – it can show you, the user, them, which is all that matters.

Then you realise you’re back with a warehouse of revisions, and looking back at history is not following the breadcrumbs left by the original developers as gospel but instead *data mining*.