Re: Adding Git to Better SCM Initiative : Comparison

Let me make a bolder statement: a person asking for "rename support" has been mentally damaged by using CVS too much.

CVS's fundamental problem is that it's a tree of versioned files. So a file has to have a well-defined identity across versions, so CVS uses the name, and that leads to problems if you rename the file.

And this is fundamentally broken. Both git and subversion do it right: a repository is a versioned tree of files. Files don't have versions, but rather versions have files. With this model, the problem Just Goes Away. It doesn't exist any more. There's nothing to solve, nothing to do.

"Rename support" is a kludge to make a fundamentally broken model less painful. Git doesn't have the problem, and so doesn't need, doesn't have, and doesn't want the kludge. Indeed, as your questions above show, it's hard to even define what it would be if it existed. It's like asking if an electric light has a thoriated mantle, or inquiring about the filament supply voltage of my mp3 player.

In all honesty, the correct answer is "no", git doesn't have that feature, just like my laptop doesn't have a cooling water pressure sensor and my solar-powered pocket calculator doesn't have a user-serviceable mains fuse.

What's broken is the feature checklist. Someone has to go and re-think the issue in a less CVS-centric way.

Just in case I was not clear enough above:

	The need for a source file to have an identity
	that persists across multiple revisions is an
	artifact of CVS's implementation.  Anyone asking
	if a different version control system can preserve
	that identity across renames needs to learn that
	we now have ways of making light without fire.

linux@horizon.com writes:

It's not.

Git _has_ rename support. Look into the code, you'll find some code whose purpose is to manage renames. And _no_, rename support is not just a direct consequence of commits being atomic.

Atomic commit help, but if you do nothing else, moving a file and then trying to merge will fail for example. So, in addition to atomic commits, you have at least 3 options : explicit file ID (bzr), recording renames (hg), or detecting renames after-the-fact (git).

On Sun, 13 January 2008, Matthieu Moy wrote:

Can't you use a name or nick, by the way?
 

Rename detection / dealing with renames in SCMs is needed for:
0. Recovering previous state
1. Merging correct files
2. Forensic (log, blame) across renames / code movement

While the fact that Git is snapshot based and has whole-tree atomic commits (Subversion does too) make it automatically obey 0., some kind of rename support is needed for merges (Better SCM has it in TODO), and for examining history, for example if the file was renamed in one of the branches.

For example "git log --follow=gitweb/gitweb.perl" follows history of specified file (IIRC this does not work for directory; but then Git does not per se tracks directories), even if it was called gitweb.cgi at the very beginning. "git blame -M" assign commit to a line denoting when line was created, and not when it was moved (perhaps across file boundaries) in the current place.

Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

Please forgive me for not mentioning that part. Yes, there are interesting things to do with renames, and git is doing them, but I skipped over them because they don't have much to do with the better-scm definition of the feature:

"Does the system support moving a file or directory to a different location while still retaining the history of the file?"

You can try to interpret it so it makes sense, but the question is basically assuming that the history is attached to the file rather than that the file is attached to the history.

With the latter model, the question is almost silly. Even with the very primitive version of git that Linus used to make v2.6.12-rc2 with none of that fancy code, you can rename a file and git retains the history. Period. The qualification "of the file" doesn't even make sense.

As Linus has observed in the past, git does lots of fancy stuff to follow the history of the code that's *in* the file, but the idea is that a file, per se, doesn't have a history or even an identity.

You can ask about the history of a file *name*, or of a file's *contents*, but if not that, what exactly is this "file" thing you want the history of?

Once you've answered that, you can then figure out if the answer to the question based on whether the file has a history to retain in the first place.

There are interesting questions about renames that you could ask, but better-scm isn't asking questions like "can you resolve merges properly after renaming a file on one branch?" Maybe I'm being uncharitable, but I can't help but read the question as asking if the system has a workaround for a well-known CVS problem. And one honest answer is "no, there's no workaround; git doesn't suffer from the problem in the first place."

I just had another look at the better-scm.org list, and noticed that someone else has already given an equivalent answer:

Vesta	Yes. The unit of checkout/checkin is a directory tree. Files and
	directories can be added, deleted, and renamed between versions.