On Thu, 30 Nov 2006, Wink Saville wrote: > > I then searched the net for how to resolve conflicts, seems you > should start by doing a git-diff, so I did and I get this: > > diff --cc kernel/fork.c > index d74b4a5,8cdd3e7..0000000 > --- a/kernel/fork.c > +++ b/kernel/fork.c > diff --cc kernel/spinlock.c > index f4d1718,2c6c2bf..0000000 > --- a/kernel/spinlock.c > +++ b/kernel/spinlock.c Hmm. That doesn't look like a conflict. If it had a real conflict, I'd have expected to see it mentioned in that diff.. This may be a stupid question, but if you haven't actually ever needed to do any file-level merges before, this may be the first time you've actually had the external 3-way "merge" program called, and that's one of the few things that git still depends on _external_ programs for. And if that program is broken or missing, you'd get bubkis. (This is hopefully getting fixed, and we'll have one less external dependency to worry about, but it's the only thing that springs to mind) That's especially true since the merge-head your log shows wasn't even all that long ago: there's just 80 commits since that common merge base, and only two of them even change those two files, and only in rather simple ways at that. So my guess is that there wasn't actually a conflict at all, but the "merge" program (usually in /usr/bin/merge) returned an error for some reason. What does "which merge" and "rpm -qf /usr/bin/merge" say? But you can also do "git diff --ours" (or "git diff --their") to get a simple two-way diff of the end result of the merge to what you were looking at. Linus - 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