use of temporary refs in resolve

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.

On Sun, 7 Aug 2005, Junio C Hamano wrote:

Absolutely not.

You forgot about one of the most common merge cases: fast-forward.

In fact, ORIG_HEAD is _the_ most common head I use explicitly. Almost all operations take HEAD as default, but doing a

	gitk ORIG_HEAD..

is extremely useful after a pull.

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

Ahhhh.  You are right.

How about LAST_MERGE?

On Sun, 7 Aug 2005, Junio C Hamano wrote:

I don't think it matters. I kind of saw it as the "other side" of ORIG_HEAD, but since we now clean it up and since I've never used it, I think it falls under the status of "well-intentioned but useless".

		Linus

Junio C Hamano <junkio@cox.net> wrote:

Is FETCH_HEAD going to be preserved by the git-fetch-script operation? It should be, unless, git-pull-script removes it or it is changed to do the fetch as well.

In a repository managed with StGIT (i.e. updated with 'stg pull'), the base of the stack is always the same with FETCH_HEAD and StGIT uses this file. I also find it quite useful for:

  gitk ORIG_HEAD..FETCH_HEAD

to only see the remote commits since the local StGIT patches are always seen as commits on top of the FETCH_HEAD. It's also useful for people using 'git rebase'.

Catalin Marinas <catalin.marinas@gmail.com> writes:

Yeah, Linus immediately corrected me when I said ORIG_HEAD seemed useless.

I am not quite sure what is being asked (especially "operation"; I take it you meant "surgery" or "butchering"), so my answer may be missing the point.

I would like to update fetch to deal with multiple references, and if the user tells it to fetch N references, the FETCH_HEAD file would contain N lines, one line for each SHA1 object name. Initially I will not allow pull to take more than one reference because I will need to make resolve capable of resolving more than two parents (i.e. octopus merge) before that happens. But once that is done, then pull will accept N references and call fetch with these N references, then fetch leaves N lines in FETCH_HEAD, and those N SHA1 object names along with the current head would be given to resolve to create an (N+1)-head king ghidorah. I do not know how well this would go, but at least that is the current plan.

Junio C Hamano <junkio@cox.net> wrote:

OK, I wasn't that clear. Currently git-fetch-script stores the fetched head in the FETCH_HEAD file and git-pull-script uses this file to do the merging (by passing its content to git-resolve-script). Anyway, I can easily change StGIT to only use git-pull-script directly, without the intermediate fetch.

It might be hard to deal with conflicts resulted from merging N > 2 heads at the same time. I suspect it would call 'merge' (diff3) for every new head but it might not be that obvious which head merging failed (it depends on how you implement it). A way of continuing the merge for the rest of the fetched heads after a failure needs to be available.

Catalin Marinas <catalin.marinas@gmail.com> writes:

Correct.  I was not planning to change that arrangement.

If you are happy then I should not complain ;-), and I am certainly not complaining, but I still have this feeling that I do not get what you are getting at. You can change it to directly use pull without intermediate fetch, in order to cope with what? Could you explain how you currently do things, and what changes I will be making would break the way you currently do things please? I need to know which detail of the current implementation behaviour people rely on to avoid breaking things.

Junio C Hamano <junkio@cox.net> wrote:

I shouldn't have said anything :-).

StGIT implements a pull command which pops all the patches from the stack, pulls the latest remote changes and pushes the patches back. I was lazy and I implemented the pulling stage by simply calling git-fetch-script and advancing the base of the stack to the value in FETCH_HEAD. I didn't have any special reason for this and I could have used git-pull-script instead and not rely on the presence of FETCH_HEAD. I don't have any preference here.

If you plan to implement multiple values in FETCH_HEAD, StGIT won't be able to use this since it doesn't do any merging for the base of the stack. As I said above, this is not a problem and I was probably wrong when decided to use git-fetch-script directly and not git-pull-script.

Please let me know if you need more info.

Catalin Marinas <catalin.marinas@gmail.com> writes:

Thanks.  Perfectly clear.