Re: Merge with git-pasky II.

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 26, 2005, 20:58 UTC
Message-ID: <Pine.LNX.4.58.0504261347520.18901@ppc970.osdl.org>
In-Reply-To: <Pine.LNX.4.44.0504261301520.4678-100000@wax.eds.org>

On Tue, 26 Apr 2005, Bram Cohen wrote:

Show 5 quoted lines

> 
> Now that you're done being dismissive, could you either (a) rebut my quite
> detailed explanation of exactly why that functionality is both a dubious
> idea and difficult to implement, or (b) admit that you have no plans
> whatsoever for supporting any of this stuff? You can't have it both ways.

I'm absolutely not going to do it myself, you're right about that.

I just don't like your notion that you should support the 5% problem with ugly hacks, and then you dismiss the 95% problem with "nothing else does it either".

In other words, we're already merging manually for the 95%. Why do you think the 5% is so important?

> What I'd really like to hear is some explanation of why git is
> reimplementing all of this stuff from scratch.

Git does in ~5000 lines and two weeks of work what _I_ think is the right thing to do. You're welcome to disagree, but the fact is, people have whined and moaned about my use of BK FOR THREE YEARS without showing me any better alternatives.

So why are you complaining now, when I implement my own version in two weeks?

> If someone offers you a dollar, no strings attached, do you turn them down
> because they didn't offer you ten?

"no strings attached"?

There are lots of strings attached to the "follow renames" thing. There's 30 _years_ of strings attached, and they result in people not looking at the _interesting_ problem.

Exactly because people follow renames, they think that they have the history of the code, but then they ignore the fact that they don't - because it doesn't follow merging of code or splitting of code.

In other words, it's sometimes better to know that you don't know the answer, than it is to _think_ that you know the answer.

> In case these concepts got conflated, I'd like to point out that Codeville
> merge both supports renames *and* does better than three-way merge can do
> at merging a single, non-renamed file.

And I'd like to point out (again) that git doesn't actually care what merge strategy the user uses.

Me _personally_, I want to have something that is very repeatable and non-clever. Something I understand _or_ tells me that it can't do it. And quite frankly, merging single-file history _without_ taking all the other files' history into account makes me go "ugh".

That's why I like the "we do _not_ look for 'nearer' parents on a per-file basis", which is what this discussion started with, afaik. I think the only original source that makes sense is the least common parent for the whole _project_, exactly because other files have done things that may or may not depend on the history of the file you're merging.

I (and thus git) really takes a "whole project" approach.

			Linus