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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mar 12, 2009, 16:34 UTC
Message-ID: <alpine.LFD.2.00.0903120929250.32478@localhost.localdomain>
In-Reply-To: <alpine.LNX.1.00.0903121024400.19665@iabervon.org>

On Thu, 12 Mar 2009, Daniel Barkalow wrote:

Show 6 quoted lines

> 
> I think one of the later refactorings may have given up on seeing 
> conflicts while reading trees, but didn't drop the flag (perhaps because 
> Linus knew at the time that my assumption that conflicts would actually 
> have been recognized was false, and didn't realize that it was also the 
> source of the flag).

That is very thoughtful of you, but I suspect the real reason was a much simpler one: redoing the read-tree logic was a huge pain in the posterior, and my primary goal at the time was to make the code more readable while passing all the tests.

So while I tried to make patches minimal (which may well explain why the flag remained), it wasn't the main goal, and trying to sort out the read-tree logic into something more understandable was quite test-driven.

So I think the big issue to take away from this is that I think this is such an odd case that if we want to support it, it would need explicit tests. Or:

> 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?

			Linus