1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-05 08:47:56 +01:00
git/contrib/examples/git-fetch.sh

380 lines
8.9 KiB
Bash
Raw Normal View History

#!/bin/sh
#
USAGE='<fetch-options> <repository> <refspec>...'
SUBDIRECTORY_OK=Yes
. git-sh-setup
set_reflog_action "fetch $*"
cd_to_toplevel ;# probably unnecessary...
. git-parse-remote
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
LF='
'
IFS="$LF"
no_tags=
tags=
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
append=
force=
Make "git fetch" less verbose by default When doing something like git fetch --tags origin the excessively verbose output of git fetch makes the result totally unreadable. It's impossible to tell if it actually fetched anything new or not, since the screen will fill up with an endless supply of ... * committish: 9165ec17fde255a1770886189359897dbb541012 tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git * refs/tags/v0.99.7c: same as tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git ... and any new tags that got fetched will be totally hidden. So add a new "--verbose" flag to "git fetch" to enable this verbose mode, but make the default be quiet. NOTE! The quiet mode will still report about new or changed heads, so if you are really fetching a new head, you'll see something like this: [torvalds@g5 git]$ git fetch --tags parent Packing 6 objects Unpacking 6 objects 100% (6/6) done * refs/tags/v1.0rc2: storing tag 'v1.0rc2' of master.kernel.org:/pub/scm/git/git * refs/tags/v1.0rc3: storing tag 'v1.0rc3' of master.kernel.org:/pub/scm/git/git * refs/tags/v1.0rc1: storing tag 'v1.0rc1' of master.kernel.org:/pub/scm/git/git which actually tells you something useful that isn't hidden by all the useless crud that you already had. Extensively tested (hey, for me, this _is_ extensive) by doing a rm .git/refs/tags/v1.0rc* and re-fetching with both --verbose and without. NOTE! This means that if the fetch didn't actually fetch anything at all, git fetch will be totally quiet. I think that's much better than being so verbose that you can't even tell whether something was fetched or not, but some people might prefer to get a "nothing to fetch" message in that case. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18 17:31:55 +01:00
verbose=
update_head_ok=
exec=
keep=
shallow_depth=
no_progress=
test -t 1 || no_progress=--no-progress
quiet=
while test $# != 0
do
case "$1" in
-a|--a|--ap|--app|--appe|--appen|--append)
append=t
;;
--upl|--uplo|--uploa|--upload|--upload-|--upload-p|\
--upload-pa|--upload-pac|--upload-pack)
shift
exec="--upload-pack=$1"
;;
--upl=*|--uplo=*|--uploa=*|--upload=*|\
--upload-=*|--upload-p=*|--upload-pa=*|--upload-pac=*|--upload-pack=*)
exec=--upload-pack=$(expr "z$1" : 'z-[^=]*=\(.*\)')
shift
;;
-f|--f|--fo|--for|--forc|--force)
force=t
;;
-t|--t|--ta|--tag|--tags)
tags=t
;;
-n|--n|--no|--no-|--no-t|--no-ta|--no-tag|--no-tags)
no_tags=t
;;
-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\
--update-he|--update-hea|--update-head|--update-head-|\
--update-head-o|--update-head-ok)
update_head_ok=t
;;
-q|--q|--qu|--qui|--quie|--quiet)
quiet=--quiet
;;
Make "git fetch" less verbose by default When doing something like git fetch --tags origin the excessively verbose output of git fetch makes the result totally unreadable. It's impossible to tell if it actually fetched anything new or not, since the screen will fill up with an endless supply of ... * committish: 9165ec17fde255a1770886189359897dbb541012 tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git * refs/tags/v0.99.7c: same as tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git ... and any new tags that got fetched will be totally hidden. So add a new "--verbose" flag to "git fetch" to enable this verbose mode, but make the default be quiet. NOTE! The quiet mode will still report about new or changed heads, so if you are really fetching a new head, you'll see something like this: [torvalds@g5 git]$ git fetch --tags parent Packing 6 objects Unpacking 6 objects 100% (6/6) done * refs/tags/v1.0rc2: storing tag 'v1.0rc2' of master.kernel.org:/pub/scm/git/git * refs/tags/v1.0rc3: storing tag 'v1.0rc3' of master.kernel.org:/pub/scm/git/git * refs/tags/v1.0rc1: storing tag 'v1.0rc1' of master.kernel.org:/pub/scm/git/git which actually tells you something useful that isn't hidden by all the useless crud that you already had. Extensively tested (hey, for me, this _is_ extensive) by doing a rm .git/refs/tags/v1.0rc* and re-fetching with both --verbose and without. NOTE! This means that if the fetch didn't actually fetch anything at all, git fetch will be totally quiet. I think that's much better than being so verbose that you can't even tell whether something was fetched or not, but some people might prefer to get a "nothing to fetch" message in that case. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18 17:31:55 +01:00
-v|--verbose)
verbose="$verbose"Yes
Make "git fetch" less verbose by default When doing something like git fetch --tags origin the excessively verbose output of git fetch makes the result totally unreadable. It's impossible to tell if it actually fetched anything new or not, since the screen will fill up with an endless supply of ... * committish: 9165ec17fde255a1770886189359897dbb541012 tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git * refs/tags/v0.99.7c: same as tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git ... and any new tags that got fetched will be totally hidden. So add a new "--verbose" flag to "git fetch" to enable this verbose mode, but make the default be quiet. NOTE! The quiet mode will still report about new or changed heads, so if you are really fetching a new head, you'll see something like this: [torvalds@g5 git]$ git fetch --tags parent Packing 6 objects Unpacking 6 objects 100% (6/6) done * refs/tags/v1.0rc2: storing tag 'v1.0rc2' of master.kernel.org:/pub/scm/git/git * refs/tags/v1.0rc3: storing tag 'v1.0rc3' of master.kernel.org:/pub/scm/git/git * refs/tags/v1.0rc1: storing tag 'v1.0rc1' of master.kernel.org:/pub/scm/git/git which actually tells you something useful that isn't hidden by all the useless crud that you already had. Extensively tested (hey, for me, this _is_ extensive) by doing a rm .git/refs/tags/v1.0rc* and re-fetching with both --verbose and without. NOTE! This means that if the fetch didn't actually fetch anything at all, git fetch will be totally quiet. I think that's much better than being so verbose that you can't even tell whether something was fetched or not, but some people might prefer to get a "nothing to fetch" message in that case. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18 17:31:55 +01:00
;;
-k|--k|--ke|--kee|--keep)
keep='-k -k'
;;
--depth=*)
shallow_depth="--depth=$(expr "z$1" : 'z-[^=]*=\(.*\)')"
;;
--depth)
shift
shallow_depth="--depth=$1"
;;
-*)
usage
;;
*)
break
;;
esac
shift
done
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
case "$#" in
0)
origin=$(get_default_remote)
test -n "$(get_remote_url ${origin})" ||
die "Where do you want to fetch from today?"
set x $origin ; shift ;;
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
esac
if test -z "$exec"
then
# No command line override and we have configuration for the remote.
exec="--upload-pack=$(get_uploadpack $1)"
fi
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
remote_nick="$1"
remote=$(get_remote_url "$@")
refs=
rref=
rsync_slurped_objects=
if test "" = "$append"
then
: >"$GIT_DIR/FETCH_HEAD"
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
fi
# Global that is reused later
ls_remote_result=$(git ls-remote $exec "$remote") ||
die "Cannot get the repository state from $remote"
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
append_fetch_head () {
flags=
test -n "$verbose" && flags="$flags$LF-v"
test -n "$force$single_force" && flags="$flags$LF-f"
GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION" \
git fetch--tool $flags append-fetch-head "$@"
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
}
# updating the current HEAD with git-fetch in a bare
# repository is always fine.
if test -z "$update_head_ok" && test $(is_bare_repository) = false
then
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
fi
# Allow --tags/--notags from remote.$1.tagopt
case "$tags$no_tags" in
'')
case "$(git config --get "remote.$1.tagopt")" in
--tags)
tags=t ;;
--no-tags)
no_tags=t ;;
esac
esac
# If --tags (and later --heads or --all) is specified, then we are
# not talking about defaults stored in Pull: line of remotes or
# branches file, and just fetch those and refspecs explicitly given.
# Otherwise we do what we always did.
reflist=$(get_remote_refs_for_fetch "$@")
if test "$tags"
then
taglist=`IFS=' ' &&
echo "$ls_remote_result" |
git show-ref --exclude-existing=refs/tags/ |
while read sha1 name
do
echo ".${name}:${name}"
done` || exit
if test "$#" -gt 1
then
# remote URL plus explicit refspecs; we need to merge them.
reflist="$reflist$LF$taglist"
else
# No explicit refspecs; fetch tags only.
reflist=$taglist
fi
fi
fetch_all_at_once () {
eval=$(echo "$1" | git fetch--tool parse-reflist "-")
eval "$eval"
( : subshell because we muck with IFS
IFS=" $LF"
(
if test "$remote" = . ; then
git show-ref $rref || echo failed "$remote"
elif test -f "$remote" ; then
test -n "$shallow_depth" &&
die "shallow clone with bundle is not supported"
git bundle unbundle "$remote" $rref ||
echo failed "$remote"
else
if test -d "$remote" &&
# The remote might be our alternate. With
# this optimization we will bypass fetch-pack
# altogether, which means we cannot be doing
# the shallow stuff at all.
test ! -f "$GIT_DIR/shallow" &&
test -z "$shallow_depth" &&
# See if all of what we are going to fetch are
# connected to our repository's tips, in which
# case we do not have to do any fetch.
theirs=$(echo "$ls_remote_result" | \
git fetch--tool -s pick-rref "$rref" "-") &&
# This will barf when $theirs reach an object that
# we do not have in our repository. Otherwise,
# we already have everything the fetch would bring in.
git rev-list --objects $theirs --not --all \
>/dev/null 2>/dev/null
then
echo "$ls_remote_result" | \
git fetch--tool pick-rref "$rref" "-"
else
flags=
case $verbose in
YesYes*)
flags="-v"
;;
esac
git-fetch-pack --thin $exec $keep $shallow_depth \
$quiet $no_progress $flags "$remote" $rref ||
echo failed "$remote"
fi
fi
) |
(
flags=
test -n "$verbose" && flags="$flags -v"
test -n "$force" && flags="$flags -f"
GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION" \
git fetch--tool $flags native-store \
"$remote" "$remote_nick" "$refs"
)
) || exit
}
fetch_per_ref () {
reflist="$1"
refs=
rref=
for ref in $reflist
do
refs="$refs$LF$ref"
# These are relative path from $GIT_DIR, typically starting at refs/
# but may be HEAD
if expr "z$ref" : 'z\.' >/dev/null
then
not_for_merge=t
ref=$(expr "z$ref" : 'z\.\(.*\)')
else
not_for_merge=
fi
if expr "z$ref" : 'z+' >/dev/null
then
single_force=t
ref=$(expr "z$ref" : 'z+\(.*\)')
else
single_force=
fi
remote_name=$(expr "z$ref" : 'z\([^:]*\):')
local_name=$(expr "z$ref" : 'z[^:]*:\(.*\)')
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
rref="$rref$LF$remote_name"
# There are transports that can fetch only one head at a time...
case "$remote" in
http://* | https://* | ftp://*)
test -n "$shallow_depth" &&
die "shallow clone with http not supported"
proto=$(expr "$remote" : '\([^:]*\):')
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
if [ -n "$GIT_CURL_FTP_NO_EPSV" -o \
"$(git config --bool http.noEPSV)" = true ]; then
noepsv_opt="--disable-epsv"
fi
# Find $remote_name from ls-remote output.
head=$(echo "$ls_remote_result" | \
git fetch--tool -s pick-rref "$remote_name" "-")
expr "z$head" : "z$_x40\$" >/dev/null ||
die "No such ref $remote_name at $remote"
echo >&2 "Fetching $remote_name from $remote using $proto"
case "$quiet" in '') v=-v ;; *) v= ;; esac
git-http-fetch $v -a "$head" "$remote" || exit
;;
rsync://*)
test -n "$shallow_depth" &&
die "shallow clone with rsync not supported"
TMP_HEAD="$GIT_DIR/TMP_HEAD"
rsync -L -q "$remote/$remote_name" "$TMP_HEAD" || exit 1
head=$(git rev-parse --verify TMP_HEAD)
rm -f "$TMP_HEAD"
case "$quiet" in '') v=-v ;; *) v= ;; esac
test "$rsync_slurped_objects" || {
rsync -a $v --ignore-existing --exclude info \
"$remote/objects/" "$GIT_OBJECT_DIRECTORY/" || exit
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
# Look at objects/info/alternates for rsync -- http will
# support it natively and git native ones will do it on
# the remote end. Not having that file is not a crime.
rsync -q "$remote/objects/info/alternates" \
"$GIT_DIR/TMP_ALT" 2>/dev/null ||
rm -f "$GIT_DIR/TMP_ALT"
if test -f "$GIT_DIR/TMP_ALT"
then
resolve_alternates "$remote" <"$GIT_DIR/TMP_ALT" |
while read alt
do
case "$alt" in 'bad alternate: '*) die "$alt";; esac
echo >&2 "Getting alternate: $alt"
rsync -av --ignore-existing --exclude info \
"$alt" "$GIT_OBJECT_DIRECTORY/" || exit
done
rm -f "$GIT_DIR/TMP_ALT"
fi
rsync_slurped_objects=t
}
;;
esac
append_fetch_head "$head" "$remote" \
"$remote_name" "$remote_nick" "$local_name" "$not_for_merge" || exit
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
done
}
fetch_main () {
case "$remote" in
http://* | https://* | ftp://* | rsync://* )
fetch_per_ref "$@"
;;
*)
fetch_all_at_once "$@"
;;
esac
}
fetch_main "$reflist" || exit
# automated tag following
case "$no_tags$tags" in
'')
case "$reflist" in
*:refs/*)
# effective only when we are following remote branch
# using local tracking branch.
taglist=$(IFS=' ' &&
echo "$ls_remote_result" |
git show-ref --exclude-existing=refs/tags/ |
while read sha1 name
do
git cat-file -t "$sha1" >/dev/null 2>&1 || continue
echo >&2 "Auto-following $name"
echo ".${name}:${name}"
done)
esac
case "$taglist" in
'') ;;
?*)
# do not deepen a shallow tree when following tags
shallow_depth=
fetch_main "$taglist" || exit ;;
esac
[PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 11:54:34 +02:00
esac
# If the original head was empty (i.e. no "master" yet), or
# if we were told not to worry, we do not have to check.
case "$orig_head" in
'')
;;
?*)
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
then
git update-ref \
-m "$GIT_REFLOG_ACTION: Undoing incorrectly fetched HEAD." \
HEAD "$orig_head"
die "Cannot fetch into the current branch."
fi
;;
esac