Re: [PATCH] read-tree A B C: do not create a bogus index and do not segfault

Linus Torvalds [off-list ref] writes:

On Thu, 12 Mar 2009, Daniel Barkalow wrote:

quoted

I think it might be a good idea to take this as evidence that nobody is 
using read-tree with multiple trees without merge, and just disallow it. 

Hmm. It _has_ been used. It's been useful for really odd things 
historically, namely trying to merge different trees by hand. So while I 
agree that we could probably remove it, it _is_ a very interesting 
feature in theory, and since we have the code.. 

So I'd say "add a few tests for the known horrible cases" should be the 
first approach. If it ever actually breaks again and becomes a big 
maintenance headache, maybe _then_ remove the feature as not being worth 
the pain?

I've added trivial tests and will start cooking it by letting it go
through the usual pu/next/master/maint cycle.

I think you are thinking about something like the "gitk" merge (aka "The
coolest merge EVER!" [*1*]), but you can do the same thing more safely
with -m option, giving an empty tree as the common ancestor.  Especially
if you run it in the aggressive mode, "addition" from our tree and their
tree, when it is an overlay, will not overlap, and will all cleanly
resolve to stage #0.

I suspect you can also use a single tree "read-tree", immediately followed
by another "read-tree --prefix=''" to read in two trees into the index and
write the results out.

[Footnote]

*1* http://article.gmane.org/gmane.comp.version-control.git/5126