Re: Merge with git-pasky II.

From: Bram Cohen <bram@bitconjurer.org>
Date: Apr 26, 2005, 20:31 UTC
Message-ID: <Pine.LNX.4.44.0504261301520.4678-100000@wax.eds.org>
In-Reply-To: <Pine.LNX.4.58.0504261256150.18901@ppc970.osdl.org>

Linus Torvalds wrote:

Show 6 quoted lines

> On Tue, 26 Apr 2005, Bram Cohen wrote:
> >
> > If one person renames a file and another person modifies it then the
> > changes should be applied to the moved file.
>
> Bzzt. Wrong answer.

I'm trying to be polite. You're not making that easy.

> The _right_ answer is "if one person moves a function, and another person
> modifies the function, the changes should be applied to the moved
> function".

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.

What I'd really like to hear is some explanation of why git is reimplementing all of this stuff from scratch. Your implicit claims that git will do more things than the other systems without having to reinvent all of their functionality first are, honestly, naive, ill-informed arrogance.

I'd like to reiterate that *nothing* out there supports moving lines between files, and further predict, with total confidence, that if git tries to support such functionality it will simply fail, either by giving up or creating a system which can behave horribly. Before you get all dismissive about this claim, please remember that I've spent years thinking about merge algorithms, and have actually designed and implemented them, and have spoken at length with other people who have done the same, while you've merely thought about them for a few weeks.

> Which is clearly a _much_ more common case than file renames.

Even if we pretend that these are comparable features, that's far from clearly true. Function moves within a file occur more frequently, but a file rename moves *all* the functions within that file.

> In other words, if your algorithm doesn't handle the latter, then there is
> no point in handling the former either.

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

> And _if_ your algorithm handles the latter, then there's no point in
> handling file renames specially, since the algorithm will have done that
> too, as a small part of it.

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. In most cases three-way and codeville merge give the same answer, but there are some cases where there isn't a single appropriate LCA available, and in those cases codeville will do the right thing while three-way can't.

-Bram