Re: Rename handling

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 19 Mar 2007, Robin Rosenberg wrote:
> 
> 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