On Sat, 30 Jul 2005, Peter Osterlund wrote:
>
> I have problems pulling linux kernel changes from
> 33ac02aa4cef417871e128ab4a6565e751e5f3b2 to
> b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first
> I thought your patch would fix it, but it doesn't:
No, this is a merge conflict failure, and you simply have conflicts in the
tree. git did everything right, it just couldn't do an automatic merge.
> ERROR: Merge conflict in arch/um/os-Linux/elf_aux.c.
> ERROR: Merge conflict in arch/x86_64/kernel/smpboot.c.
> ERROR: Merge conflict in drivers/i2c/busses/i2c-mpc.c.
> ERROR: Merge conflict in include/asm-i386/bitops.h.
> ERROR: Merge conflict in kernel/sys.c.
We don't have any nice graphical tools to show these to you like BitKeeper
had, although it shouldn't be fundamentally hard.
What you need to do is basically edit all those five files, and look for
the conflicts (they are just like normal CVS conflicts:
<<<<<<<
orig-branch
conflict-contents
=======
pulled-branch
conflict-contents
>>>>>>>>
and then you edit them to your liking until you have no more conflicts,
and then you have to commit your manual resolve with
git commit --all
which will commit the merge _and_ your manual conflict resolution.
This is something where a nice wrapper layer could do a lot better. I know
there are graphical three-way merge programs available.
But core git is no worse (and in fact a _lot_ better) than CVS in this
regard, so I feel that the git merge, while obviously not perfect or even
very smart, is "sufficient" for what git is (ie it's up to porcelain to do
anything better).
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
