2005-05-22 22:03:24 +04:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
2005-12-14 01:30:31 +03:00
|
|
|
|
|
|
|
USAGE='<fetch-options> <repository> <refspec>...'
|
2006-12-14 11:36:23 +03:00
|
|
|
SUBDIRECTORY_OK=Yes
|
2005-11-24 11:12:11 +03:00
|
|
|
. git-sh-setup
|
2006-12-28 10:34:48 +03:00
|
|
|
set_reflog_action "fetch $*"
|
2007-01-12 23:49:05 +03:00
|
|
|
cd_to_toplevel ;# probably unnecessary...
|
2006-12-28 10:34:48 +03:00
|
|
|
|
2005-09-08 04:26:23 +04:00
|
|
|
. 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 13:54:34 +04: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"
|
|
|
|
|
2005-10-11 10:22:02 +04:00
|
|
|
LF='
|
|
|
|
'
|
|
|
|
IFS="$LF"
|
|
|
|
|
2006-01-07 11:48:04 +03:00
|
|
|
no_tags=
|
2005-09-30 01:35:15 +04:00
|
|
|
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 13:54:34 +04:00
|
|
|
append=
|
2005-08-23 08:28:33 +04:00
|
|
|
force=
|
2005-11-18 19:31:55 +03:00
|
|
|
verbose=
|
2005-08-26 05:15:32 +04:00
|
|
|
update_head_ok=
|
2006-01-20 21:05:24 +03:00
|
|
|
exec=
|
2006-11-02 01:06:22 +03:00
|
|
|
keep=
|
2006-10-30 22:09:53 +03:00
|
|
|
shallow_depth=
|
2005-08-23 08:28:33 +04:00
|
|
|
while case "$#" in 0) break ;; esac
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-a|--a|--ap|--app|--appe|--appen|--append)
|
|
|
|
append=t
|
|
|
|
;;
|
2006-01-27 05:11:06 +03:00
|
|
|
--upl|--uplo|--uploa|--upload|--upload-|--upload-p|\
|
|
|
|
--upload-pa|--upload-pac|--upload-pack)
|
2006-01-20 21:05:24 +03:00
|
|
|
shift
|
2007-01-23 11:51:53 +03:00
|
|
|
exec="--upload-pack=$1"
|
|
|
|
;;
|
|
|
|
--upl=*|--uplo=*|--uploa=*|--upload=*|\
|
|
|
|
--upload-=*|--upload-p=*|--upload-pa=*|--upload-pac=*|--upload-pack=*)
|
2007-01-30 21:11:49 +03:00
|
|
|
exec=--upload-pack=$(expr "z$1" : 'z-[^=]*=\(.*\)')
|
2007-01-23 11:51:53 +03:00
|
|
|
shift
|
2006-01-20 21:05:24 +03:00
|
|
|
;;
|
2005-08-23 08:28:33 +04:00
|
|
|
-f|--f|--fo|--for|--forc|--force)
|
|
|
|
force=t
|
2005-08-26 05:15:32 +04:00
|
|
|
;;
|
2005-09-30 01:35:15 +04:00
|
|
|
-t|--t|--ta|--tag|--tags)
|
|
|
|
tags=t
|
|
|
|
;;
|
2006-01-07 11:48:04 +03:00
|
|
|
-n|--n|--no|--no-|--no-t|--no-ta|--no-tag|--no-tags)
|
|
|
|
no_tags=t
|
|
|
|
;;
|
2005-08-26 05:15:32 +04:00
|
|
|
-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
|
2005-08-23 08:28:33 +04:00
|
|
|
;;
|
2005-11-18 19:31:55 +03:00
|
|
|
-v|--verbose)
|
|
|
|
verbose=Yes
|
|
|
|
;;
|
2006-01-11 04:50:19 +03:00
|
|
|
-k|--k|--ke|--kee|--keep)
|
2006-11-02 01:06:25 +03:00
|
|
|
keep='-k -k'
|
2006-01-11 04:50:19 +03:00
|
|
|
;;
|
2006-10-30 22:09:53 +03:00
|
|
|
--depth=*)
|
|
|
|
shallow_depth="--depth=`expr "z$1" : 'z-[^=]*=\(.*\)'`"
|
|
|
|
;;
|
|
|
|
--depth)
|
|
|
|
shift
|
|
|
|
shallow_depth="--depth=$1"
|
|
|
|
;;
|
2005-12-14 01:30:31 +03:00
|
|
|
-*)
|
|
|
|
usage
|
|
|
|
;;
|
2005-08-23 08:28:33 +04:00
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
2005-08-26 05:15:32 +04:00
|
|
|
shift
|
2005-08-23 08:28:33 +04:00
|
|
|
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 13:54:34 +04:00
|
|
|
case "$#" in
|
|
|
|
0)
|
2006-09-23 14:05:43 +04:00
|
|
|
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 13:54:34 +04:00
|
|
|
esac
|
2005-08-23 08:28:33 +04:00
|
|
|
|
2007-01-25 07:45:39 +03:00
|
|
|
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 13:54:34 +04:00
|
|
|
remote_nick="$1"
|
|
|
|
remote=$(get_remote_url "$@")
|
|
|
|
refs=
|
|
|
|
rref=
|
|
|
|
rsync_slurped_objects=
|
|
|
|
|
|
|
|
if test "" = "$append"
|
|
|
|
then
|
2005-10-05 20:58:10 +04:00
|
|
|
: >"$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 13:54:34 +04:00
|
|
|
fi
|
|
|
|
|
2006-11-23 08:57:14 +03:00
|
|
|
# Global that is reused later
|
2007-01-23 11:51:53 +03:00
|
|
|
ls_remote_result=$(git ls-remote $exec "$remote") ||
|
2006-12-18 23:16:58 +03:00
|
|
|
die "Cannot get the repository state from $remote"
|
2006-11-23 08:57:14 +03:00
|
|
|
|
[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 13:54:34 +04:00
|
|
|
append_fetch_head () {
|
|
|
|
head_="$1"
|
|
|
|
remote_="$2"
|
|
|
|
remote_name_="$3"
|
|
|
|
remote_nick_="$4"
|
|
|
|
local_name_="$5"
|
2005-09-26 09:54:23 +04:00
|
|
|
case "$6" in
|
|
|
|
t) not_for_merge_='not-for-merge' ;;
|
|
|
|
'') not_for_merge_= ;;
|
|
|
|
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 13:54:34 +04:00
|
|
|
|
2005-09-02 13:34:13 +04:00
|
|
|
# remote-nick is the URL given on the command line (or a shorthand)
|
|
|
|
# remote-name is the $GIT_DIR relative refs/ path we computed
|
|
|
|
# for this refspec.
|
2006-03-10 15:19:07 +03:00
|
|
|
|
|
|
|
# the $note_ variable will be fed to git-fmt-merge-msg for further
|
|
|
|
# processing.
|
2005-09-02 13:34:13 +04:00
|
|
|
case "$remote_name_" in
|
|
|
|
HEAD)
|
|
|
|
note_= ;;
|
|
|
|
refs/heads/*)
|
|
|
|
note_="$(expr "$remote_name_" : 'refs/heads/\(.*\)')"
|
2005-09-22 00:59:54 +04:00
|
|
|
note_="branch '$note_' of " ;;
|
2005-09-02 13:34:13 +04:00
|
|
|
refs/tags/*)
|
|
|
|
note_="$(expr "$remote_name_" : 'refs/tags/\(.*\)')"
|
2005-09-22 00:59:54 +04:00
|
|
|
note_="tag '$note_' of " ;;
|
2006-03-10 15:19:07 +03:00
|
|
|
refs/remotes/*)
|
|
|
|
note_="$(expr "$remote_name_" : 'refs/remotes/\(.*\)')"
|
|
|
|
note_="remote branch '$note_' of " ;;
|
2005-09-02 13:34:13 +04:00
|
|
|
*)
|
2005-09-22 00:59:54 +04:00
|
|
|
note_="$remote_name of " ;;
|
2005-09-02 13:34:13 +04:00
|
|
|
esac
|
2006-04-14 02:01:24 +04:00
|
|
|
remote_1_=$(expr "z$remote_" : 'z\(.*\)\.git/*$') &&
|
2005-09-22 00:59:54 +04:00
|
|
|
remote_="$remote_1_"
|
|
|
|
note_="$note_$remote_"
|
2005-09-02 13:34:13 +04:00
|
|
|
|
[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 13:54:34 +04:00
|
|
|
# 2.6.11-tree tag would not be happy to be fed to resolve.
|
|
|
|
if git-cat-file commit "$head_" >/dev/null 2>&1
|
|
|
|
then
|
2005-08-25 09:46:07 +04:00
|
|
|
headc_=$(git-rev-parse --verify "$head_^0") || exit
|
2005-10-05 20:58:10 +04:00
|
|
|
echo "$headc_ $not_for_merge_ $note_" >>"$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 13:54:34 +04:00
|
|
|
else
|
2005-10-05 20:58:10 +04:00
|
|
|
echo "$head_ not-for-merge $note_" >>"$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 13:54:34 +04:00
|
|
|
fi
|
2006-10-01 07:33:05 +04:00
|
|
|
|
|
|
|
update_local_ref "$local_name_" "$head_" "$note_"
|
[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 13:54:34 +04:00
|
|
|
}
|
|
|
|
|
2006-10-01 07:33:05 +04:00
|
|
|
update_local_ref () {
|
|
|
|
# If we are storing the head locally make sure that it is
|
|
|
|
# a fast forward (aka "reverse push").
|
|
|
|
|
|
|
|
label_=$(git-cat-file -t $2)
|
|
|
|
newshort_=$(git-rev-parse --short $2)
|
|
|
|
if test -z "$1" ; then
|
|
|
|
[ "$verbose" ] && echo >&2 "* fetched $3"
|
|
|
|
[ "$verbose" ] && echo >&2 " $label_: $newshort_"
|
|
|
|
return 0
|
|
|
|
fi
|
2006-10-01 11:42:40 +04:00
|
|
|
oldshort_=$(git show-ref --hash --abbrev "$1" 2>/dev/null)
|
|
|
|
|
[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 13:54:34 +04:00
|
|
|
case "$1" in
|
|
|
|
refs/tags/*)
|
|
|
|
# Tags need not be pointing at commits so there
|
|
|
|
# is no way to guarantee "fast-forward" anyway.
|
2006-10-01 11:42:40 +04:00
|
|
|
if test -n "$oldshort_"
|
2005-08-23 08:28:33 +04:00
|
|
|
then
|
2006-10-01 11:42:40 +04:00
|
|
|
if now_=$(git show-ref --hash "$1") && test "$now_" = "$2"
|
2005-10-19 05:42:14 +04:00
|
|
|
then
|
2006-10-01 07:33:05 +04:00
|
|
|
[ "$verbose" ] && echo >&2 "* $1: same as $3"
|
|
|
|
[ "$verbose" ] && echo >&2 " $label_: $newshort_" ||:
|
2005-10-19 05:42:14 +04:00
|
|
|
else
|
|
|
|
echo >&2 "* $1: updating with $3"
|
2006-10-01 07:33:05 +04:00
|
|
|
echo >&2 " $label_: $newshort_"
|
2006-12-28 10:34:48 +03:00
|
|
|
git-update-ref -m "$GIT_REFLOG_ACTION: updating tag" "$1" "$2"
|
2005-10-19 05:42:14 +04:00
|
|
|
fi
|
2005-08-23 08:28:33 +04:00
|
|
|
else
|
2005-09-02 13:34:13 +04:00
|
|
|
echo >&2 "* $1: storing $3"
|
2006-10-01 07:33:05 +04:00
|
|
|
echo >&2 " $label_: $newshort_"
|
2006-12-28 10:34:48 +03:00
|
|
|
git-update-ref -m "$GIT_REFLOG_ACTION: storing tag" "$1" "$2"
|
2005-08-23 08:28:33 +04:00
|
|
|
fi
|
2005-09-28 05:14:27 +04:00
|
|
|
;;
|
2005-08-23 08:28:33 +04:00
|
|
|
|
2006-03-10 15:19:07 +03:00
|
|
|
refs/heads/* | refs/remotes/*)
|
2005-09-28 05:14:27 +04:00
|
|
|
# $1 is the ref being updated.
|
|
|
|
# $2 is the new value for the ref.
|
|
|
|
local=$(git-rev-parse --verify "$1^0" 2>/dev/null)
|
|
|
|
if test "$local"
|
2005-08-12 13:08:29 +04:00
|
|
|
then
|
2005-09-28 05:14:27 +04:00
|
|
|
# Require fast-forward.
|
[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 13:54:34 +04:00
|
|
|
mb=$(git-merge-base "$local" "$2") &&
|
|
|
|
case "$2,$mb" in
|
|
|
|
$local,*)
|
2006-06-04 10:44:40 +04:00
|
|
|
if test -n "$verbose"
|
|
|
|
then
|
|
|
|
echo >&2 "* $1: same as $3"
|
2006-10-01 07:33:05 +04:00
|
|
|
echo >&2 " $label_: $newshort_"
|
2006-06-04 10:44:40 +04:00
|
|
|
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 13:54:34 +04:00
|
|
|
;;
|
|
|
|
*,$local)
|
2005-09-02 13:34:13 +04:00
|
|
|
echo >&2 "* $1: fast forward to $3"
|
2006-10-01 07:33:05 +04:00
|
|
|
echo >&2 " old..new: $oldshort_..$newshort_"
|
2006-12-28 10:34:48 +03:00
|
|
|
git-update-ref -m "$GIT_REFLOG_ACTION: fast-forward" "$1" "$2" "$local"
|
[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 13:54:34 +04:00
|
|
|
;;
|
|
|
|
*)
|
|
|
|
false
|
|
|
|
;;
|
|
|
|
esac || {
|
2005-09-28 05:14:27 +04:00
|
|
|
case ",$force,$single_force," in
|
|
|
|
*,t,*)
|
2006-10-01 07:33:05 +04:00
|
|
|
echo >&2 "* $1: forcing update to non-fast forward $3"
|
|
|
|
echo >&2 " old...new: $oldshort_...$newshort_"
|
2006-12-28 10:34:48 +03:00
|
|
|
git-update-ref -m "$GIT_REFLOG_ACTION: forced-update" "$1" "$2" "$local"
|
2005-08-23 08:28:33 +04:00
|
|
|
;;
|
|
|
|
*)
|
2006-10-01 07:33:05 +04:00
|
|
|
echo >&2 "* $1: not updating to non-fast forward $3"
|
|
|
|
echo >&2 " old...new: $oldshort_...$newshort_"
|
2006-03-17 09:04:18 +03:00
|
|
|
exit 1
|
2005-08-23 08:28:33 +04:00
|
|
|
;;
|
|
|
|
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 13:54:34 +04:00
|
|
|
}
|
|
|
|
else
|
2005-09-28 05:14:27 +04:00
|
|
|
echo >&2 "* $1: storing $3"
|
2006-10-01 07:33:05 +04:00
|
|
|
echo >&2 " $label_: $newshort_"
|
2006-12-28 10:34:48 +03:00
|
|
|
git-update-ref -m "$GIT_REFLOG_ACTION: storing head" "$1" "$2"
|
2005-08-12 13:08:29 +04:00
|
|
|
fi
|
2005-07-05 22:38:37 +04:00
|
|
|
;;
|
[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 13:54:34 +04:00
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2007-01-07 13:17:52 +03: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
|
2005-09-28 05:14:27 +04:00
|
|
|
orig_head=$(git-rev-parse --verify HEAD 2>/dev/null)
|
2007-01-07 13:17:52 +03:00
|
|
|
fi
|
2005-08-26 05:15:32 +04:00
|
|
|
|
2007-02-15 12:46:27 +03:00
|
|
|
# Allow --notags from remote.$1.tagopt
|
|
|
|
case "$tags$no_tags" in
|
|
|
|
'')
|
|
|
|
case "$(git-config --get "remote.$1.tagopt")" in
|
|
|
|
--no-tags)
|
|
|
|
no_tags=t ;;
|
|
|
|
esac
|
|
|
|
esac
|
|
|
|
|
2005-09-30 01:35:15 +04:00
|
|
|
# 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
|
2006-12-18 04:57:19 +03:00
|
|
|
taglist=`IFS=' ' &&
|
2006-11-23 08:57:14 +03:00
|
|
|
echo "$ls_remote_result" |
|
2007-02-12 00:41:23 +03:00
|
|
|
git-show-ref --exclude-existing=refs/tags/ |
|
2006-01-06 06:42:12 +03:00
|
|
|
while read sha1 name
|
|
|
|
do
|
2007-02-12 00:41:23 +03:00
|
|
|
echo ".${name}:${name}"
|
2006-07-10 14:34:34 +04:00
|
|
|
done` || exit
|
2005-09-30 01:35:15 +04:00
|
|
|
if test "$#" -gt 1
|
|
|
|
then
|
|
|
|
# remote URL plus explicit refspecs; we need to merge them.
|
2005-10-11 10:22:02 +04:00
|
|
|
reflist="$reflist$LF$taglist"
|
2005-09-30 01:35:15 +04:00
|
|
|
else
|
|
|
|
# No explicit refspecs; fetch tags only.
|
|
|
|
reflist=$taglist
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
2006-01-07 11:48:04 +03:00
|
|
|
fetch_main () {
|
|
|
|
reflist="$1"
|
|
|
|
refs=
|
2006-09-29 22:05:40 +04:00
|
|
|
rref=
|
2005-07-16 11:16:24 +04:00
|
|
|
|
2006-01-07 11:48:04 +03:00
|
|
|
for ref in $reflist
|
|
|
|
do
|
|
|
|
refs="$refs$LF$ref"
|
2005-07-16 11:16:24 +04:00
|
|
|
|
2006-01-07 11:48:04 +03:00
|
|
|
# These are relative path from $GIT_DIR, typically starting at refs/
|
|
|
|
# but may be HEAD
|
2006-04-14 02:01:24 +04:00
|
|
|
if expr "z$ref" : 'z\.' >/dev/null
|
2006-01-07 11:48:04 +03:00
|
|
|
then
|
|
|
|
not_for_merge=t
|
2006-04-14 02:01:24 +04:00
|
|
|
ref=$(expr "z$ref" : 'z\.\(.*\)')
|
2006-01-07 11:48:04 +03:00
|
|
|
else
|
|
|
|
not_for_merge=
|
|
|
|
fi
|
2006-04-14 06:05:38 +04:00
|
|
|
if expr "z$ref" : 'z+' >/dev/null
|
2006-01-07 11:48:04 +03:00
|
|
|
then
|
|
|
|
single_force=t
|
2006-04-14 06:05:38 +04:00
|
|
|
ref=$(expr "z$ref" : 'z+\(.*\)')
|
2006-01-07 11:48:04 +03:00
|
|
|
else
|
|
|
|
single_force=
|
|
|
|
fi
|
2006-04-14 02:01:24 +04:00
|
|
|
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 13:54:34 +04:00
|
|
|
|
2006-01-07 11:48:04 +03:00
|
|
|
rref="$rref$LF$remote_name"
|
2005-09-17 22:56:41 +04:00
|
|
|
|
2006-01-07 11:48:04 +03:00
|
|
|
# There are transports that can fetch only one head at a time...
|
|
|
|
case "$remote" in
|
2006-09-14 06:24:04 +04:00
|
|
|
http://* | https://* | ftp://*)
|
2006-10-30 22:09:53 +03:00
|
|
|
test -n "$shallow_depth" &&
|
|
|
|
die "shallow clone with http not supported"
|
2006-10-25 14:03:06 +04:00
|
|
|
proto=`expr "$remote" : '\([^:]*\):'`
|
2006-01-07 11:48:04 +03:00
|
|
|
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
|
|
|
|
curl_extra_args="-k"
|
|
|
|
fi
|
2006-09-29 04:10:44 +04:00
|
|
|
if [ -n "$GIT_CURL_FTP_NO_EPSV" -o \
|
2007-01-29 03:16:53 +03:00
|
|
|
"`git-config --bool http.noEPSV`" = true ]; then
|
2006-09-29 04:10:44 +04:00
|
|
|
noepsv_opt="--disable-epsv"
|
|
|
|
fi
|
2006-11-23 09:24:09 +03:00
|
|
|
|
|
|
|
# Find $remote_name from ls-remote output.
|
|
|
|
head=$(
|
|
|
|
IFS=' '
|
|
|
|
echo "$ls_remote_result" |
|
|
|
|
while read sha1 name
|
|
|
|
do
|
|
|
|
test "z$name" = "z$remote_name" || continue
|
|
|
|
echo "$sha1"
|
|
|
|
break
|
|
|
|
done
|
|
|
|
)
|
2006-04-14 02:01:24 +04:00
|
|
|
expr "z$head" : "z$_x40\$" >/dev/null ||
|
2006-11-23 09:24:09 +03:00
|
|
|
die "No such ref $remote_name at $remote"
|
2006-10-25 14:03:06 +04:00
|
|
|
echo >&2 "Fetching $remote_name from $remote using $proto"
|
2006-01-07 11:48:04 +03:00
|
|
|
git-http-fetch -v -a "$head" "$remote/" || exit
|
|
|
|
;;
|
|
|
|
rsync://*)
|
2006-10-30 22:09:53 +03:00
|
|
|
test -n "$shallow_depth" &&
|
|
|
|
die "shallow clone with rsync not supported"
|
2006-01-07 11:48:04 +03:00
|
|
|
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"
|
|
|
|
test "$rsync_slurped_objects" || {
|
|
|
|
rsync -av --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 13:54:34 +04:00
|
|
|
|
2006-01-07 11:48:04 +03: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
|
|
|
|
}
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
# We will do git native transport with just one call later.
|
|
|
|
continue ;;
|
|
|
|
esac
|
2005-07-16 11:16:24 +04:00
|
|
|
|
2006-01-07 11:48:04 +03:00
|
|
|
append_fetch_head "$head" "$remote" \
|
2006-11-25 12:04:28 +03:00
|
|
|
"$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 13:54:34 +04:00
|
|
|
|
2006-01-07 11:48:04 +03:00
|
|
|
done
|
|
|
|
|
|
|
|
case "$remote" in
|
2006-09-14 06:24:04 +04:00
|
|
|
http://* | https://* | ftp://* | rsync://* )
|
2006-01-07 11:48:04 +03:00
|
|
|
;; # we are already done.
|
|
|
|
*)
|
|
|
|
( : subshell because we muck with IFS
|
|
|
|
IFS=" $LF"
|
|
|
|
(
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 03:59:14 +03:00
|
|
|
if 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
|
2007-01-01 23:24:15 +03:00
|
|
|
git-fetch-pack --thin $exec $keep $shallow_depth "$remote" $rref ||
|
|
|
|
echo failed "$remote"
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 03:59:14 +03:00
|
|
|
fi
|
2006-01-07 11:48:04 +03:00
|
|
|
) |
|
2007-01-01 23:24:15 +03:00
|
|
|
(
|
|
|
|
trap '
|
|
|
|
if test -n "$keepfile" && test -f "$keepfile"
|
|
|
|
then
|
|
|
|
rm -f "$keepfile"
|
|
|
|
fi
|
|
|
|
' 0
|
|
|
|
|
|
|
|
keepfile=
|
|
|
|
while read sha1 remote_name
|
|
|
|
do
|
2006-01-07 11:48:04 +03:00
|
|
|
case "$sha1" in
|
|
|
|
failed)
|
|
|
|
echo >&2 "Fetch failure: $remote"
|
|
|
|
exit 1 ;;
|
2006-11-02 01:06:25 +03:00
|
|
|
# special line coming from index-pack with the pack name
|
|
|
|
pack)
|
|
|
|
continue ;;
|
|
|
|
keep)
|
2007-01-01 23:24:15 +03:00
|
|
|
keepfile="$GIT_OBJECT_DIRECTORY/pack/pack-$remote_name.keep"
|
2006-11-02 01:06:25 +03:00
|
|
|
continue ;;
|
2006-01-07 11:48:04 +03:00
|
|
|
esac
|
|
|
|
found=
|
|
|
|
single_force=
|
|
|
|
for ref in $refs
|
|
|
|
do
|
|
|
|
case "$ref" in
|
|
|
|
+$remote_name:*)
|
|
|
|
single_force=t
|
|
|
|
not_for_merge=
|
|
|
|
found="$ref"
|
|
|
|
break ;;
|
|
|
|
.+$remote_name:*)
|
|
|
|
single_force=t
|
|
|
|
not_for_merge=t
|
|
|
|
found="$ref"
|
|
|
|
break ;;
|
|
|
|
.$remote_name:*)
|
|
|
|
not_for_merge=t
|
|
|
|
found="$ref"
|
|
|
|
break ;;
|
|
|
|
$remote_name:*)
|
|
|
|
not_for_merge=
|
|
|
|
found="$ref"
|
|
|
|
break ;;
|
|
|
|
esac
|
|
|
|
done
|
2006-04-14 02:01:24 +04:00
|
|
|
local_name=$(expr "z$found" : 'z[^:]*:\(.*\)')
|
2006-01-07 11:48:04 +03:00
|
|
|
append_fetch_head "$sha1" "$remote" \
|
2006-11-25 12:04:28 +03:00
|
|
|
"$remote_name" "$remote_nick" "$local_name" \
|
|
|
|
"$not_for_merge" || exit
|
2007-01-01 23:24:15 +03:00
|
|
|
done
|
|
|
|
)
|
2006-01-07 11:48:04 +03:00
|
|
|
) || exit ;;
|
|
|
|
esac
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2006-11-25 12:04:28 +03:00
|
|
|
fetch_main "$reflist" || exit
|
2006-01-07 11:48:04 +03:00
|
|
|
|
|
|
|
# automated tag following
|
|
|
|
case "$no_tags$tags" in
|
|
|
|
'')
|
2006-02-23 00:10:37 +03:00
|
|
|
case "$reflist" in
|
|
|
|
*:refs/*)
|
|
|
|
# effective only when we are following remote branch
|
|
|
|
# using local tracking branch.
|
2006-12-18 04:57:19 +03:00
|
|
|
taglist=$(IFS=' ' &&
|
2006-11-23 08:57:14 +03:00
|
|
|
echo "$ls_remote_result" |
|
2006-12-18 04:57:19 +03:00
|
|
|
git-show-ref --exclude-existing=refs/tags/ |
|
2006-02-23 00:10:37 +03:00
|
|
|
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
|
2006-01-07 11:48:04 +03:00
|
|
|
case "$taglist" in
|
|
|
|
'') ;;
|
|
|
|
?*)
|
2006-11-24 17:59:12 +03:00
|
|
|
# do not deepen a shallow tree when following tags
|
|
|
|
shallow_depth=
|
2006-11-25 12:04:28 +03:00
|
|
|
fetch_main "$taglist" || exit ;;
|
2006-01-07 11:48:04 +03:00
|
|
|
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 13:54:34 +04:00
|
|
|
esac
|
2005-08-26 05:15:32 +04:00
|
|
|
|
|
|
|
# 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.
|
2006-10-11 09:29:02 +04:00
|
|
|
case "$orig_head" in
|
|
|
|
'')
|
2005-08-26 05:15:32 +04:00
|
|
|
;;
|
2006-10-11 09:29:02 +04:00
|
|
|
?*)
|
2005-09-28 05:14:27 +04:00
|
|
|
curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)
|
2005-08-26 05:15:32 +04:00
|
|
|
if test "$curr_head" != "$orig_head"
|
|
|
|
then
|
2006-07-11 07:38:35 +04:00
|
|
|
git-update-ref \
|
2006-12-28 10:34:48 +03:00
|
|
|
-m "$GIT_REFLOG_ACTION: Undoing incorrectly fetched HEAD." \
|
2006-07-11 07:38:35 +04:00
|
|
|
HEAD "$orig_head"
|
2005-08-26 05:15:32 +04:00
|
|
|
die "Cannot fetch into the current branch."
|
|
|
|
fi
|
|
|
|
;;
|
|
|
|
esac
|