Re: Merge with git-pasky II.

From: David Woodhouse <dwmw2@infradead.org>
Date: Apr 15, 2005, 15:29 UTC
Message-ID: <1113578964.27227.65.camel@hades.cambridge.redhat.com>
In-Reply-To: <Pine.LNX.4.58.0504150740310.7211@ppc970.osdl.org>

On Fri, 2005-04-15 at 07:53 -0700, Linus Torvalds wrote:

Show 9 quoted lines

> Files DO NOT matter. Never have. It's an implementation limitation to 
> think they do. You'll screw yourself up, and when somebody comes up with a 
> half-way efficient way to generate inter-fiel diffs, your architecture is 
> totally and utterly unable to handle it.
> 
> I don't care what you do at an SCM level, and if the crud you put on top
> of git wants to perpetuate mistakes of yesteryear, that's _your_ issue.  
> But dammit, git is designed to do the right thing, and I will fight tooth
> and nail against anybody who thinks individual files matter.

No, really: individual files _DO_ matter. There's a reason we split stuff up into separate files, and if you look closely you'll find that we don't just randomly put different functions into different files with neither rhyme nor reason -- there's a pattern to it; usually some kind of functional grouping.

And when I'm looking for the change that broke something, I can almost always tell which file it's in and go looking in _that_ file. It's a _whole_ lot easier to use the equivalent of 'bk revtool' than it is to sift through all the unrelated commits in the whole tree. If that's an implementation limitation, then it's an implementation limitation in my _brain_ not just in my tools.

OK, in fact it shouldn't be 'show me the history of this file'; it's often really 'show me the history of this function' which I want. But that's fine. All I'm suggesting is that we should include the metadata which says "content moved from file XXX to file YYY" along with the commit objects.

I'm certainly not suggesting that we should implement jejb's idea of explicit 'file revision history' objects -- the tree-based philosophy is perfectly sane and sufficient. But we do _also_ need a little information which allows us to track content as it moves around within the tree, and the SCM has to have a sane way to filter out the noise when we're looking for what broke. Yes, that's part of the SCM functionality, and can live in an xattr-type field in the commit object -- but it does need to be stored, and in practice I suspect it _will_ be useful for merging too.

It's not about ditching the per-tree tracking and doing per-file tracking instead. I agree that would be wrong. It's about storing enough information to track what happened to given content as it moved around within the tree.

-- 
dwmw2