From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Subject: Multi-head pulling series
Date: Thu, 18 Aug 2005 00:24:28 -0700 [thread overview]
Message-ID: <7vek8rlnbn.fsf@assigned-by-dhcp.cox.net> (raw)
Here is the current status of the multi-head download support.
[PATCH 1/3] Start adding the $GIT_DIR/remotes/ support.
[PATCH 2/3] Multi-head fetch.
[PATCH 3/3] Update git-pull to match updated git-fetch.
The first one in the series adds support for the long promised
$GIT_DIR/remotes/ files; they use the following format:
$ cat $GIT_DIR/remotes/www
URL: http://www.kernel.org/pub/scm/git/git.git/
Pull: master:ko-master pu:ko-pu
$ cat $GIT_DIR/remotes/mko
URL: master.kernel.org:/pub/scm/git/git.git/
Pull: master:ko-master pu:ko-pu
Push: master:master pu:pu foo:bar
The idea is that you should be able to say:
$ git push mko ;# push our master and pu to the same
# name, foo to .git/refs/heads/bar.
$ git push mko pu:refs/heads/testing
# instead of pushing to the usual ref,
# push our pu to refs/heads/testing,
# this time only.
$ git fetch www ;# get their master and pu to our ko-master
# and ko-pu.
$ git pull www bar
# instead of fetching from usual ref,
# fetch from there bar, and merge with it.
Having a Push: entry that uses anything but hostname:/path or
just local directory as its URL does not make any sense at this
moment, because git native send-pack transport is the only one
that is supported for push, as before.
Note that using a $GIT_DIR/branches/ file as a short-cut is
still supported, for both upload and download.
The second one extends "git fetch" to allow pulling from more
than one head. Earlier, "git fetch <remote>" with shorthand
form (i.e. a file $GIT_DIR/branches/<remote> exists and
describes the URL) always overwrote
$GIT_DIR/refs/heads/<remote>, but it does the "reverse push",
meaning it does not overwrite when the update does not result in
a fast-forward merge with the existing value of the reference.
The above "git fetch www" example would fetch both their master
and pu, and tries to fast forward our ko-master and ko-pu with
them. When fast forwarding fails, currently it just stops and
does not try to download all the heads. This may need to
change. The fetch results, whether they update the local
refs/heads/ hierarchy by fast forwarding or not, will be also
stored in $GIT_DIR/FETCH_HEAD.
Note that the format of this file has changed to accomodate
multiple heads. I've checked that neither Cogito nor StGIT
looks at this file, so this change should hopefully be a safe
one.
The third one is to update the "git pull" to prevent people from
abusing the extended "git fetch" and attempt to create a king
ghidorah. "git resolve" has not been updated to do anything but
two-head merge yet, so when you say "git pull www master pu rc",
it would run "git fetch www master pu rc" but stops without
running the resolving step. While it would not make much sense
xsto do an octopus merge against master, pu and rc from git.git
repository, doing an octopus would probably make a lot more
sense when pulling from a repository like what Jeff Garzik has,
so that would be an interesting future project.
I have tested the very basic form of the above works reasonably
well, but there probably are bugs, maybe attempting to pull
heads to a wrong local heads, or something silly like that.
Please handle it with care. It will stay in "pu" branch for
now.
next reply other threads:[~2005-08-18 7:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-18 7:24 Junio C Hamano [this message]
2005-08-18 7:39 ` [PATCH 1/3] Start adding the $GIT_DIR/remotes/ support Junio C Hamano
2005-08-18 7:39 ` [PATCH 2/3] Multi-head fetch Junio C Hamano
2005-08-18 7:39 ` [PATCH 3/3] Update git-pull to match updated git-fetch Junio C Hamano
2005-08-18 10:45 ` Multi-head pulling series Josef Weidendorfer
2005-08-20 18:54 ` Junio C Hamano
2005-08-22 16:35 ` Josef Weidendorfer
2005-08-23 1:07 ` Junio C Hamano
2005-08-23 5:37 ` 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=7vek8rlnbn.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).