Re: Multi-ancestor read-tree notes

From: Junio C Hamano <junkio@cox.net>
Date: Sep 6, 2005, 21:53 UTC
Message-ID: <7vslwhg8xe.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0509061610080.23242@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

> Good. (Although that patch doesn't seem to be directly on top of my 
> version; I can tell what it's doing anyway)

That one was against the proposed updates head. I've updated it again to include the patch.

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

Again, that is up to you. I am not _that_ perfectionist but I do not mind reapplying updated ones if you are ;-).

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

I do not understand what you meant by '*' and 'index+' in one-way merge table. I take the first row ('*') to mean "If the tree is missing a path, that path is removed from the index."

I like the second sentence in three-way merge description. That is a very easy-to-understand description of what the index requirements are.

You have 2 2ALTs. Also 14 and 14ALT look like they are the same rule now.

What's "(empty)^" in "ancest"? All of them must be empty for this rule to apply?

I am not quite sure it is 'a suitable replacement' yet; the existing table you can see it covers all the cases, but with things like "'ancestor+' means one of them matches", I cannot really tell the table covers all the cases or some cases fall of the end of the chain.

Also when we have more than one ancestors or one remotes and we say "no merge", it is still unspecified (and I have to admit I cannot readily say what the result should be for all of them, except that I agree #16 will be fine with an empty stage1) what are left in which stages.

I personally think the exotic cases (i.e. no rule applies, or "no merge" result with more than one ancestors/remotes) needs to be handled outside read-tree anyway, by the script that drives read-tree to attempt trivial merges. That is the core of the git-resolve-script would become:

    bases=`git-merge-base -a $ours $theirs` || exit
    git-read-tree -m -u $bases $ours $theirs
    case "$?" in
    0)
        # trivially resolved; nothing to do.
        ;;
    1)
        # no exotic cases -- just do it the old way.
    	git-merge-cache -o git-merge-one-file-script -a ;;
    2)
        # exotic cases like #16 and any other.
        # maybe try different heuristics, like best-base, from
        # scratch.
        git-read-tree --reset $ours
        ... attempt different merge policies ...
        ;;
    esac

So in that sense it probably does not matter what we leave in stage1/2/3 in such cases as long as the command fails in such a way that allows us to tell what happened.