From: Catalin Marinas <catalin.marinas@gmail.com>
To: Junio C Hamano <junkio@cox.net>
Cc: Linus Torvalds <torvalds@osdl.org>, git@vger.kernel.org
Subject: Re: use of temporary refs in resolve
Date: Mon, 08 Aug 2005 11:26:20 +0100 [thread overview]
Message-ID: <tnxr7d4vi5v.fsf@arm.com> (raw)
In-Reply-To: <7vfytkdcgm.fsf@assigned-by-dhcp.cox.net> (Junio C. Hamano's message of "Mon, 08 Aug 2005 02:06:49 -0700")
Junio C Hamano <junkio@cox.net> wrote:
> Catalin Marinas <catalin.marinas@gmail.com> 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
next prev parent reply other threads:[~2005-08-08 10:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-07 19:44 use of temporary refs in resolve Junio C Hamano
2005-08-07 20:02 ` Linus Torvalds
2005-08-07 20:12 ` Junio C Hamano
2005-08-07 20:18 ` Linus Torvalds
2005-08-08 8:50 ` Catalin Marinas
2005-08-08 9:06 ` Junio C Hamano
2005-08-08 10:26 ` Catalin Marinas [this message]
2005-08-09 2:48 ` Junio C Hamano
2005-08-09 9:07 ` Catalin Marinas
2005-08-09 12:51 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tnxr7d4vi5v.fsf@arm.com \
--to=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.