Multi-head pulling series
- From
Junio C Hamano <junkio@cox.net>
- Date
- Aug 18, 2005, 07:24 UTC
- Message-ID
- <7vek8rlnbn.fsf@assigned-by-dhcp.cox.net>
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.