Re: More gitweb queries..

TG> Note: If I pull into an empty tree (no HEAD) there is only one head in TG> this array which corresponds to the remote_head. Otherwise the first TG> element is *always* the local HEAD.

"An empty tree (no HEAD)"? Is your definition of "an empty tree" the same as "empty" directory after you do "mkdir empty && cd empty && git-init-db", followed by bunch of git-*-pull to get the objects and commits from other reposititories being involved in the merge but without touching .git/HEAD? If so, why cannot I do the git-*-pull from multiple repositories and merge them together? Why "there is only one head in this array that is remote_head"? Oh, I guess I am missing your definition of "remote_head". Puzzled...

Anyhow I presume that if your ${GIT-.git}/HEAD exists, you include it as the first element of MERGE_HEADS.

TG> I have a function merge which gets a sorted array of heads. Heads can be TG> unlimited at the time because some of the heads can be included into TG> other heads (they're a subset) and so they don't show up in the commit TG> object. I call this array MERGE_HEADS.

Sorry I am not very good at this "thinking" thing, and I need to draw pictures. Please bear with me.

    (line of dev C)-------------C    We are here, trying to merge
    (line of dev B)---(merge)---B    these three lines of devs:
    (line of dev A)---A/             A, B and C

    MERGE_HEADS = (A B C)
    A is actually a "subset" of B

Is this what you mean by "subset"? Are these "subset" HEAD the only thing that causes fast forwards?

My gut feeling without thinking much is that it might be easier to first cull such fast forward heads by using N-way rev-tree before you do anything else. If only one head survives after that, then that head would be your new head and you do not have to go through any merges. Otherwise you merge those independent heads without worrying about fast forwards. How does that sound?