Re: Rename handling

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mar 19, 2007, 20:34 UTC
Message-ID: <Pine.LNX.4.64.0703191323490.6730@woody.linux-foundation.org>
In-Reply-To: <200703192102.20258.robin.rosenberg.lists@dewire.com>

On Mon, 19 Mar 2007, Robin Rosenberg wrote:

Show 6 quoted lines

> 
> How about this simple receipe for defeating rename tracking (real world):
> 
> User needs to modify A. User renames A to OLD_A within his/her IDE. SCM
> records the rename. User now uses SaveAs to restore A, and SCM detects the 
> *NEW* file A.

Well, the thing is, I don't think that's a very strong argument against rename tracking.

You can always make trivial examples of when something goes wrong. Computers (and SCM's) are stupid, and they simply do what they are told. Just about *any* policy can be trivially show to be "totally broken" by having a user do something - usually something very simple - that breaks it on purpose.

Similarly, I don't think it's hard to show examples of where git's "content is king" does something that the user thinks could be done much better. And similarly, I don't think that's an argument against the content model that git uses.

No, the reason I like the content model is that there is never any hidden state that doesn't matter for the user. If you're a physicist, you could say that yhere is never any "action at a distance" with git. There are no hidden linkages that aren't obvious in the source tree that you commit or work on.

In contrast, the very *definition* of "explicit rename tracking" is to track those hidden linkages. They aren't visible to the developer, except when they clash, and that very invisibility is what makes both mistakes so easy (anybody who claims that they never do a rename as a del/add pair is simply lying or not doing very interesting development) *and* it is what makes handling merges so hard (because when there is a conflict, the conflict isn't actually in anything that is *visible*!).

I also pretty much guarantee that the reason git development has been so fast, stable and trouble-free comes exactly from the simple conceptual mindset and very concrete implementation. There simply are never any subtle issues. Content is content is content. It has no "history". Yes, git shows history, but it's literally a "series of snapshots", and the trees that are checked out are totally history-less.

In contrast, if you have file rename tracking, then those trees are no longer stateless - they have an implied history associated with them, that matters. It's largely *invisible*, but that just makes it worse!

			Linus