On Tue, 6 Sep 2005, Junio C Hamano wrote: > Daniel Barkalow <[EMAIL PROTECTED]> writes: > > > Do you know if there's anything like case #16 in there? I'd be interested > > to know if there's anything that gets handled automatically in different > > ways depending on which single base is used, and doesn't require manual > > intervention with multiple bases, because that's probably wrong. > > Re-running the tests with the attached patch shows there weren't any.
Good. (Although that patch doesn't seem to be directly on top of my version; I can tell what it's doing anyway) > > Great. Want me to send the patches with better organization, or are you > > set with what I've sent? > > That's up to you. If you are content with what I have in the pu > branch, there is no need to bother resending. OTOH if you have > further clean-ups in mind, i.e. "better organization" above, I > do not mind dropping the current ones from "pu" and replace them > with another set from you. I'm happy with the content in "pu"; the issue is just whether you want the history cleaned up more. In the series I sent, I kept forgetting parts that belonged in earlier patches. Could you look over the documentation in Documentation/technical/trivial-merge.txt, and see if it's a suitable replacement for the table in t1000-read-tree-m-3way.sh? It should be the same, except for ALT or non-ALT versions that we're not using, combining a few matching cases, describing the rules behind index requirements rather than listing outcomes, and the addition of info on how multiple ancestors are handled. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html