Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Thu, 12 Mar 2009, Daniel Barkalow wrote: > >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
