Re: Multi-ancestor read-tree notes

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Sep 6, 2005, 20:25 UTC
Message-ID: <Pine.LNX.4.63.0509061610080.23242@iabervon.org>
In-Reply-To: <7vbr36j75b.fsf@assigned-by-dhcp.cox.net>

On Tue, 6 Sep 2005, Junio C Hamano wrote:

Show 8 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> 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)

Show 8 quoted lines

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