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
