On Thu, 12 Mar 2009, Daniel Barkalow wrote:
quoted text
> 
> 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:

quoted text
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html