From: Junio C Hamano <junkio@cox.net>
Date: Sun, 07 Aug 2005 19:44:35 GMT
Subject: use of temporary refs in resolve
Message-ID: <7v3bplwmzg.fsf@assigned-by-dhcp.cox.net>

As promised I was looking into the fetching side today, but I
ended up trying to figure out the current operation of resolve
first.

Here is my understanding of various "temporary heads" left
directly underneath $GIT_DIR:

    HEAD      : updated only after successful auto merge.

    ORIG_HEAD : records the head value before resolve started.
                if automerge fails, this is the same as HEAD,
                but after successful automerge, this can be used
                to see what the previous head was.  This is the
                first parent of the resulting commit.

    MERGE_HEAD: present if auto merge is unsuccessful and
		records the other head being merged.

    LAST_MERGE: present if merge is unsuccessful or impossible and
		records the other head being merged.

Whenever resolve fails, LAST_MERGE would be there, while
MERGE_HEAD exists only when we attempted and failed an
automerge.  I would propose to change this to leave LAST_MERGE
only when we did not even attempt to automerge.

Also ORIG_HEAD is probably redundant.  After a successful
automerge, the same information can be had by HEAD^1, and after
a failure, it is HEAD.  We do not use the existence of that file
to detect if we are in a middle of the merge (MERGE_HEAD is used
for that purpose by git-commit).  We may want stop writing to it
in git-resolve.

What do you think?

Another thing I was thinking was to give git-resolve an ability
to take more than two commits to do octopus ;-).  Instead of
using the third argument as a merge commit message, we would say
(for backward compatibilities' sake) the last one is the
message.  When we fail halfway, things would probably become messy,
so this needs be postponed until some more thought.