Merge conflicts as .rej .orig files

After using arch for a while, I've gotten used to getting .rej and
.orig files instead of big ugly conflict markers inside the file.
Emacs has a nice 'diff' mode that is a boon when dealing with
conflicts this way.

Is there a way to convince cogito/git to leave reject files around?
What utility is git using to do the merges? Or at least: where should
I look?

cheers,


martin

On Fri, 19 Aug 2005, Martin Langhoff wrote:

Is there a way to convince cogito/git to leave reject files around?

Nope.

Git just doesn't deal in patches. There's never any patch rejects: there 
are just two source files that get merged.

The ".orig" and ".rej" things are signs of patch-based systems. 

I'm sure you could fake it, but I'm also sure that there's an emacs mode 
for the "merge" style diffs. It is, after all, what CVS and RCS have used, 
so I'd expect that there be tons of support for making it look nice and 
help merges.

		Linus

On Fri, 19 Aug 2005, Martin Langhoff wrote:

After using arch for a while, I've gotten used to getting .rej and
.orig files instead of big ugly conflict markers inside the file.
Emacs has a nice 'diff' mode that is a boon when dealing with
conflicts this way.

Is there a way to convince cogito/git to leave reject files around?
What utility is git using to do the merges? Or at least: where should
I look?

I believe you should be able to get that effect by having a version
of "git-merge-one-script" that does "diff -c $2 $3 | patch $1" or "diff -c
$2 $1 | patch $3", depending on which you want as the orig. (Or something
like that. I'm not sure exactly how to get the conflict files out of the
script and into the right place, or the arguments it gets.)

Of course, you'll probably have more conflicts to deal with, because the
merging code gets less information that way. (In particular, you'll lose
the "already contains changes" behavior, so you'll be unhappy if you have
patches merged upstream.)

	-Daniel
*This .sig left intentionally blank*