Out-tree merges

  Hello,

  I've been thinking about it, and although it seemed Just Sensible
initially, I'm liking it less and less now that I'm actually doing
out-tree merges (git merge already supports it). What is the motivation
of doing things outside of your working directory?

  The only one I can imagine is that it could interfere with some local
changes in your directory. And I think that this does not make sense.
Either you are going to keep them and you should commit them, or you
don't and there's no reason for keeping them around. Is this really that
common for you?

  I have two counter-arguments. First, you likely can't build the thing
in your merge tree, so you can't check if it even compiles after the
merge went through. Second, you need to work quite differently when
working in a merge tree. You can't grep for stuff, you cannot (without
thinking about it and going to different directories) peek to header
files to check if this structure member is really __u32, etc. You might
do all of this when merging, let's say when solving weird conflicts.

  Of course being better off with your working directory assumes that
you have one. OTOH it is hardly imaginable for me that you would all of
sudden want to say "hey, now I want to take these two trees all of
sudden and void and merge them together". Not in any common real world
cases.  Or am I wrong?

  So, I'm thinking whether to just revert to the original behaviour of
doing the merges in the working tree, or make it optional (which would
make the scripts more complicated and convoluted).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor