Re: Merge with git-pasky II.

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 15, 2005, 14:53 UTC
Message-ID: <Pine.LNX.4.58.0504150740310.7211@ppc970.osdl.org>
In-Reply-To: <1113556448.12012.269.camel@baythorne.infradead.org>

On Fri, 15 Apr 2005, David Woodhouse wrote:

> 
> I suspect that finding the common commit is actually a per-file thing;
> it's not just something you do for the _commit_ graph, then use for
> merging each file in the two branches you're trying to merge.

I disagree.

Conceptually, you should never do _anything_ on a file level. Why? Because individual files don't matter. You shouldn't merge two files cleanly just because they look fine - they _depend_ on the other files in the archive, and that's quite fundamentally why per-file tracking is really wrong from a project standpoint.

So if you can't merge two files cleanly because the "project" history ended up being further back than the "file" history, then that's a _good_ thing. You don't know what the hell happened to the other files that this file depended on. Merging one file independently of the others is WRONG.

Also, I suspect that you'll find that if you do cross-merges, you'll basically always end up in:

> (I think it's a coincidence that in my example the useful files 'A2' and
> 'B2' actually do end up in a single tree together at some point.)

nope, I don't think that's coincidence. I think that's the normal case. Your file-based history is the one that can _incorrectly_ and coincidentally happen to have a single file at some point, but since that file doesn't stand alone, that's really not a fundamentally good reason to merge it.

Really, this "individual files matter" approach is a _disease_. They don't. Individual files DO NOT EXIST. Files always exist as part of the project, and the _only_ time you track a single file is when the project is a single file (and then that will be very very obvious in a git archive, thank you very much).

So the single-file mentality is a disease brought on by decades of _crap_. And by the fact that it ends up limiting the problem scope, so you can do certain things easier.

For example, just doing intra-file diffs is a lot _easier_ and less time-consuming than doing inter-file diffs. Bit it is _absolutely_ not better. In fact, it is clearly inferior to anybody who spends even five seconds thinking about it - yet we still do it, because of the historical (and INCORRECT) mindset that "files matter".

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.

		Linus