Re: Handling renames.

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 14, 2005, 18:32 UTC
Message-ID: <Pine.LNX.4.58.0504141124220.7211@ppc970.osdl.org>
In-Reply-To: <20050414181224.GA16126@elte.hu>

On Thu, 14 Apr 2005, Ingo Molnar wrote:

Show 5 quoted lines

> 
> there's no redundancy caused by this method: only renames (which are 
> rare) go through the rename_commit redirection. (to speed up the lookup 
> the rename_commit object could cache the offset of the two names within 
> their tree objects.)

Bzzt. Wrong.

ANYTHING you do with games like this will cause the "same directory creates different object" crap.

Git doesn't do that. There fundamentally is no history in objects, _except_ for the commit object. Two objects with the same name are identical, and that means that they are easy to share.

Any time you break that model, you break the whole point of git. Don't do it. You'll be very very sorry if you ever do, because it breaks the clean separation of "time" and "space". I guarantee you that your merges will become _harder_ rather than easier.

What you can do at an SCM level, is that if you want to track renames, you track them as a separate commit altogether. Ie if you notice a rename, you first commit the rename (and you can _see_ it's a rename, since the object didn't change, and the sha1 stayed the same, which in git-speak means that it is the same object, ie that _is_ a rename as far as git is concerned), and then you create the "this is the data that changed" as a _second_ commit.

But don't make it a new kind of commit. It's just a regular commit, dammit. No new abstractions.

Trust me, it's worth it to follow the rules. You don't start making up new concepts for every new thing you track. Next you'll want "tag objects". That's a totally idiotic idea. What you do is you tag things at a higher level than git ever is, and git will _never_ have to know about tag objects.

Some "higher level" thing can add its own rules _on_top_ of git rules. The same way we have normal applications having their _own_ rules on top of the kernel. You do abstraction in layers, but for this to work, the base you build on top of had better be damn solid, and not have any ugly special cases.

		Linus