On 2009.09.15 23:53:03 +0200, Martin Langhoff wrote: > 2009/9/15 Björn Steinbrink <B.Steinbrink@xxxxxx>: > > Sooner or later you'll hit a merge conflict anyway, and conflict markers > > aren't that hard to understand, and IMHO are easier to handle than .rej > > files, as you get to edit everything in-place. > > When git's diff3 gets confused trying to use ancestry, the conflict > markers bring completely unrelated things that belong to the history > of the file and not to the patch at hand. > > It's not about the conflict markers but somewhat nonsensical proposed > "sides" to the resolution. That's not git getting confused trying to use the ancestry, but git being unable to make use of the history. It has to use a fake common ancestor, as using the true common ancestor would obviously mean that you do a real merge, not a cherry-pick. Under some circumstances that can lead to quite "interesting" conflicts, yeah, but IMHO still better to deal with than those .rej files, especially when you switch to diff3 conflict marker mode (git checkout --conflict=diff3 -- file), which also contains the version of the code that the "common ancestor" has. > > Well, you likely shouldn't be using git-apply, which is plumbing, and > > can't easily make use of the "index" information in git patches to do a > > three-way merge instead of a "stupid" patch application. Instead use > > git-am --3way to make git perform a three-way merge, leading to > > conflicts instead of plain patch rejection. > > Um, you got your internals wrong. git-apply is what git-am uses. No, you didn't understand what I said. I said that _you_ shouldn't be using git-apply. That "git am" internally uses "git apply" is a totally different story. And with --3way, it doesn't even run just "git apply < patch", but uses "git apply" just to build a fake common ancestor and does a 3-way merge with git-merge-recursive. Björn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html