Daniel Barkalow <[EMAIL PROTECTED]> 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.

-
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

Reply via email to