Re: resolve (merge) problems

Luben Tuikov [off-list ref] writes:

$ git resolve HEAD master "merge linus' tree"
Trying to merge 5666c0947ede0432ba5148570aa66ffb9febff5b into
32df3299405fb7054b76346899f3db2fa29150fb using 458af5439fe7ae7d95ca14106844e61f0795166c.
Simple merge failed, trying Automatic merge
Removing arch/arm/configs/poodle_defconfig
Removing drivers/atm/atmdev_init.c
fatal: merge program failed
Automatic merge failed, fix up by hand

How do I proceed from here?

The output from git-diff-index is:

$git-diff-index --name-status HEAD
M       Documentation/usb/error-codes.txt
M       Makefile
M       arch/arm/configs/corgi_defconfig
U       arch/arm/configs/poodle_defconfig
M       arch/arm/configs/spitz_defconfig

Easier to read is:

	$ git-diff-files --name-status

which would tell you that there two files have conflicting
changes:

U       arch/arm/configs/poodle_defconfig
U       drivers/atm/atmdev_init.c

and you would hopefully not see anything else (you saw tons of
paths only because you compared against HEAD, which shows not
just conflicts but everything the merge brought in).

	$ git diff arch/arm/configs/poodle_defconfig drivers/atm/atmdev_init.c

would give you the diff between your version (before merging)
and the half-merged file with conflict markers.  Resolve them
just like you would resolve conflicting changes.  I would
usually just open these files in an editor, and pick one of the
sections between <<< == >>> these markers.

One nifty tool I saw suggested on the list recently was xxdiff:

	$ xxdiff -U arch/arm/configs/poodle_defconfig

No matter how you would resolve, the first goal of yours is to
get these files in your working tree into a good shape, which
may involve compiling and testing.  Once you have these files in
a good enough shape, you tell git that you are done with them:

	$ git update-index \
        	arch/arm/configs/poodle_defconfig drivers/atm/atmdev_init.c

and commit.

	$ git commit

The commit message editor would loudly warn you that you are
committing a merge, but that is OK because that is what you are
doing.  You might want to describe how you resolved (which side
you picked) the conflicting changes in the log, in addition to
the standard boilerplate "merged that branch" message.