Re: [PATCH] Fall back to three-way merge when applying a patch.

On Wed, 5 Oct 2005, Eric W. Biederman wrote:

Not workable.

It fundamentally only works for the first patch in a series. After that, the rest will be based off a version that the recipient simply doesn't have (well, if it's the _tree_ SHA1, and the recipient has no other patches, then they'll match, but that case is uninteresting, since it's the trivial case that you always get right by just applying the things in the first place).

So you'd have to make it the base for the patch _series_, at a minimum.

And even that likely doesn't work very often. Any time you have a private merge or some other patch in your tree, the recipient wouldn't be able to parse it.

In practice, I've found that most often it's very trivially obvious _why_ a patch doesn't apply (I remember the "other patch" that happened to the same file, or I just do a "git-whatchanged -p filename"), and it can be useful to allow the person applying the patch to say "ok, try to apply it against version xyz, and do a three-way merge".

But it really tends to be fairly rare.

Now obviously, some of that may be kernel-specific - a large part of the lack of patch conflicts is that we over the years have actively tried to set up the kernel sources so that people seldom step on each other (one example is how we have all modules contain their own "init_module()" thing and sortign it out in the linker - because the old init/main.c approach was _very_ painful since everybody wanted to add lines to the same file).

So it may turn out that other projects might have different wishes for how something like this would work. But I doubt it works very well to rely on commit-level SHA1's - it's more likely to work if you try the "last few tagged releases etc", since patches that don't apply are often against the previous release (and if they don't apply there either, then it's probably not worth fighting over anyway).

		Linus