Sorry to be so ignorant, but I just updated to 2.6.19 using:
   git-checkout master

   git-pull
   ...

   sound/usb/usbaudio.c                          |    3

   usr/Makefile                                  |    2

   92 files changed, 888 insertions(+), 371 deletions(-)

   create mode 100644 arch/mips/kernel/topology.c

   create mode 100644 arch/um/os-Linux/execvp.c

   create mode 100644 include/asm-arm/mach/udc_pxa2xx.h
All seemed to go I then moved back to my branch and pulled from master to my branch:
   git-checkout ace

   git-pull . master
But that failed:
   Trying really trivial in-index merge...

   fatal: Merge requires file-level merging

   Nope.

   Merging HEAD with 0215ffb08ce99e2bb59eca114a99499a4d06e704

   Merging:

   d7083db038fb98266e331a7f96198ec35a12367a A partial fix BUG 061124 (crashing when 1ms interrrupts).

   0215ffb08ce99e2bb59eca114a99499a4d06e704 Linux 2.6.19

   found 1 common ancestor(s):

   1abbfb412b1610ec3a7ec0164108cee01191d9f5 [PATCH] x86_64: fix bad page state in process 'swapper'

   Auto-merging kernel/fork.c

   CONFLICT (content): Merge conflict in kernel/fork.c

   Auto-merging kernel/spinlock.c

   CONFLICT (content): Merge conflict in kernel/spinlock.c
   Automatic merge failed; fix conflicts and then commit the result.
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
And git-status shows:
   # On branch refs/heads/ace

   #

   # Updated but not checked in:

   #   (will commit)

   #

   #       modified: Documentation/rtc.txt

   #       modified: Makefile

   #       modified: arch/arm/configs/assabet_defconfig

   #       modified: arch/arm/configs/cerfcube_defconfig

   ......

   #       modified: sound/usb/usbaudio....
[ message continues ]

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

-

Side note: the historically more common failure was to not have a merge

program at all, but exactly because that was common, we check for that and

complain about it. So that's not it for you - you do have a 'merge'

program somewhere that git found.
But if it returns the wrong error code, or doesn't do anything at all (ie

you have "merge", but it's not the 3-way merge we expect, or it doesn't

take the "-L" argument we use, or it's simply buggy) then that might

explain the behaviour you report.
Or it might be something totally different. This is just a wild theory.
		Linus

-

Earlier had a problem with git wanting merge but didn't have it and

couldn't figure out which package it was in Ubuntu:( So I symlinked merge

to kdiff3 which worked at the time:
wink@winkc2d1:~/linux/linux-2.6$ ls -al /usr/bin/merge

lrwxrwxrwx 1 root root 6 2006-11-17 19:24 /usr/bin/merge -> kdiff3
But doesn't/didn't work this time.
I tried "git diff --ours"
wink@winkc2d1:~/linux/linux-2.6$ git diff --ours

* Unmerged path kernel/fork.c

diff --git a/kernel/fork.c b/kernel/fork.c

* Unmerged path kernel/spinlock.c

diff --git a/kernel/spinlock.c b/kernel/spinlock.c

wink@winkc2d1:~/linux/linux-2.6$
Wink
Not too helpful:(
-

[ Tangentially related.. ]
Btw, what's the status of the xdl_merge() thing in "pu"?
It would be lovely if this could be one less thing we ever need to worry

about, just because we just do it ourselves. But quite frankly, I've never

looked at the RCS merge logic, so while I peeked at the xdl_merge patch

itself, I have absolutely zero way of judging it.
But the patch in "pu" to make merge-recursive use it looks pretty, and

removes more lines than it adds, and the xdl_merge() code itself _looked_

sane even if I can't judge the algorithm, so... 
Anyway, here's one vote for trying to move this thing into "next" (first

asking whether all of Dscho's fixup patches got merged too?). 
I realize that git-cvsserver (and my toy merge-file.c that isn't used by

anything real) also use the external merge program, so we can't remove the

dependency entirely (both in git.spec.in and documentation) without fixing

those too, but at least we would _practically_ be able to ignore it for

all normal users. And cvsserver would probably be quite fixable too..
			Linus

-

Ahh. I'm pretty sure that is it.
No, kdiff3 probably doesn't have the same semantics, so better get the

"real" merge. It's almost certainly in the rcs package, so "emerge rcs"

should do it.
Or whatever system Ubuntu uses. 
		Linus

-

..and just to be safe, remove the symlink first, so that you don't end up

overwriting the "kdiff3" binary by mistake when you install the real

"merge". Not that I think emerge is quite that stupid a package manager,

but anyway..
		Linus

-

Ubuntu is debian based and I use Synaptic GUI, a front end to apt-get. My earlier problem

was I couldn't find which package "merge" was in. But now I just figured it out by going

to debian.org and using "Search the contents of packages" for "merge". Turns out "merge"

is in devel/rcs which of course the whole world knows, unless your a neophyte like me:)
Any way after getting the real merge, I reverted the first pull and re-did it and all was well:
wink@winkc2d1:~/linux/linux-2.6$ git-checkout -f

wink@winkc2d1:~/linux/linux-2.6$ git-status

# On branch refs/heads/ace

nothing to commit

wink@winkc2d1:~/linux/linux-2.6$ git-pull . master

Trying really trivial in-index merge...

fatal: Merge requires file-level merging

Nope.

Merging HEAD with 0215ffb08ce99e2bb59eca114a99499a4d06e704

Merging:

d7083db038fb98266e331a7f96198ec35a12367a A partial fix BUG 061124 (crashing when 1ms interrrupts).

0215ffb08ce99e2bb59eca114a99499a4d06e704 Linux 2.6.19

found 1 common ancestor(s):

1abbfb412b1610ec3a7ec0164108cee01191d9f5 [PATCH] x86_64: fix bad page state in process 'swapper'

Auto-merging kernel/fork.c

Auto-merging kernel/spinlock.c
Merge made by recursive.

  Documentation/rtc.txt                         |  463 ++++++++++++++++---------

  Makefile                                      |    2

  arch/arm/configs/assabet_defconfig            |    1

  arch/arm/configs/cerfcube_defconfig           |    1

  arch/arm/configs/corgi_defconfig              |    1

......

  sound/pci/emu10k1/emu10k1_main.c              |    1

  sound/pci/hda/patch_realtek.c                 |    2

  sound/pci/hda/patch_sigmatel.c                |   14 -

  sound/usb/usbaudio.c                          |    3

  usr/Makefile                                  |    2

  92 files changed, 888 insertions(+), 371 deletions(-)

  create mode 100644 arch/mips/kernel/topology.c

  create mode 100644 arch/um/os-Linux/execvp.c

  create mode 100644 include/asm-arm/mach/udc_pxa2xx.h
Thank you very much,
Wink
-

I'm actually using Debian Unstable and basically use the git-core package. Its

at version 1.4.4.1 - so right up to date, and of course resolves all

dependencies automatically.
Doesn't Ubuntu have git-core in its repository?
--

Alan Chandler

http://www.chandlerfamily.org.uk

-

It was an older version, so I started at the source.
W
-

Ubuntu is a Debian based.  I think it uses Synaptic as its package manager gui

with the standard Debian apt-xxx tools underneath.

--

Alan Chandler

http://www.chandlerfamily.org.uk

-

On Friday 01 December 2006 07:06, Wink Saville wrote:

I am not the worlds expert in this, but since most seem to be in bed I'll

attempt to answer you
These show that these two files had some conflicts in the contents from the

kernel and your local branch
Take a look in these two files - you should see conflict markers of the form

<<<<<<<<<<<<<<<<

some content

================
which is the contents that failed from your side and the new version of the

kernel you pulled in.
Edit so the files have sensible content
then use
git update-index <filename>
to tell git that that particular conflict has been resolved.
When you have done that for both files
just do 
git commit
--

Alan Chandler

http://www.chandlerfamily.org.uk

-

That's what I thought but there isn't any "<<<<<" and git-diff also seems

to indicate no differences:
wink@winkc2d1:~/linux/linux-2.6$ git-diff kernel/fork.c

diff --cc kernel/fork.c

index d74b4a5,8cdd3e7..0000000

--- a/kernel/fork.c

+++ b/kernel/fork.c

wink@winkc2d1:~/linux/linux-2.6$
wink@winkc2d1:~/linux/linux-2.6$ git-diff kernel/spinlock.c

diff --cc kernel/spinlock.c

index f4d1718,2c6c2bf..0000000

--- a/kernel/spinlock.c

+++ b/kernel/spinlock.c

wink@winkc2d1:~/linux/linux-2.6$
Thanks,
Wink

-

This is at the limit of my understanding, but perhaps file permission problems

could have been the cause (was also thinking white space - but to my

recollection is that that DOES cause resolution markers) 
I think you'll have to wait for experts from the list to comment.

--

Alan Chandler

http://www.chandlerfamily.org.uk

-