Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Catalin Marinas <[EMAIL PROTECTED]> writes:
>> 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.
>
> 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.

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.

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

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

-
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