On Thu, 30 Nov 2006, Wink Saville wrote:
quoted text
> 
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html