* efficient cloning
@ 2006-03-19 21:16 James Cloos
2006-03-19 22:31 ` Shawn Pearce
2006-03-19 23:18 ` Junio C Hamano
0 siblings, 2 replies; 22+ messages in thread
From: James Cloos @ 2006-03-19 21:16 UTC (permalink / raw)
To: git
Is there a way to accomplish the effect of this script w/o having to
download any unnecessary objects?
==================================================
#!/bin/bash
lt="/gits/linux-2.6/.git"
if [ $# -ne 2 ]; then
echo >&2 "Usage: $0 <repo> <target-dir>"
exit 1
fi
git-clone $1 $2
mkdir -p $2/objects/info
{
test -f "$lt/objects/info/alternates" &&
cat "$lt/objects/info/alternates";
echo "$lt/objects"
} >"$2/objects/info/alternates"
cd $2
git-repack -a -d -s
git-prune-packed
==================================================
I tried to modify git-clone to add an alternates file before calling
fetch, but that file just gets deleted.
I presume I need to clone -s -l the local alternate, re-parent it to
the new URL and grab anything missing, but how can I assure that it
results in exactly the same repo as this script?
I'm often behind tiny straws, so efficiency is important.
-JimC
--
James H. Cloos, Jr. <cloos@jhcloos.com>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: efficient cloning 2006-03-19 21:16 efficient cloning James Cloos @ 2006-03-19 22:31 ` Shawn Pearce 2006-03-19 23:18 ` Junio C Hamano 1 sibling, 0 replies; 22+ messages in thread From: Shawn Pearce @ 2006-03-19 22:31 UTC (permalink / raw) To: James Cloos; +Cc: git James Cloos <cloos@jhcloos.com> wrote: > Is there a way to accomplish the effect of this script w/o having to > download any unnecessary objects? > > ================================================== > #!/bin/bash > > lt="/gits/linux-2.6/.git" > > if [ $# -ne 2 ]; then > echo >&2 "Usage: $0 <repo> <target-dir>" > exit 1 > fi > > git-clone $1 $2 > mkdir -p $2/objects/info > { > test -f "$lt/objects/info/alternates" && > cat "$lt/objects/info/alternates"; > echo "$lt/objects" > } >"$2/objects/info/alternates" > > cd $2 > git-repack -a -d -s > git-prune-packed > ================================================== > > I tried to modify git-clone to add an alternates file before calling > fetch, but that file just gets deleted. > > I presume I need to clone -s -l the local alternate, re-parent it to > the new URL and grab anything missing, but how can I assure that it > results in exactly the same repo as this script? Exactly right. There was some discussion about this perhaps just two weeks back and it become clear that the easiest way to clone through a thin straw is to use `git clone -s -l' from a locally available repository which is ``close''[*1*] to the remote you are going to actually trying to clone from, edit .git/remotes/origin to have the correct URL: and Pull: lines, then `git-pull origin' to bring down whatever you don't have yet. This won't miss any objects so it will result in the same repository as a clone would have[*2*]. Footnotes: [*1*] Here ``close'' means probably related to the same project. Meaning if you are cloning the Linux kernel at least start with another kernel repository and not say the GIT repository. :-) The more your original repository has in common with the remote you are trying to pull from the less that will need to be downloaded. [*2*] This isn't entirely true. During a normal clone everything is pulled down into a single pack. Using this strategy the missing objects that are downloaded will be loose; a git-repack after the pull might be a good idea to pull them into a pack. -- Shawn. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-19 21:16 efficient cloning James Cloos 2006-03-19 22:31 ` Shawn Pearce @ 2006-03-19 23:18 ` Junio C Hamano 2006-03-20 0:32 ` James Cloos 1 sibling, 1 reply; 22+ messages in thread From: Junio C Hamano @ 2006-03-19 23:18 UTC (permalink / raw) To: James Cloos; +Cc: git James Cloos <cloos@jhcloos.com> writes: > I presume I need to clone -s -l the local alternate, re-parent it to > the new URL and grab anything missing, but how can I assure that it > results in exactly the same repo as this script? "The same repo as this script" is a very poor way to define what you really want. What is "git-repack -a -d -s"? Guessing what you perhaps are trying to do: - You have /gits/linux-2.6/.git on your local disk that is a reasonably recent copy of the upstream Linux 2.6 repository. - You want to clone from whatever $1 is (maybe a subsystem tree, but we cannot tell from your question) to a new directory $2. - Presumably you know whatever $1 is is related to Linus repository and would want to take advantage of the fact that it shares many objects with /gits/linux-2.6/.git It might be worth adding a --reference flag to git-clone like this patch does. However, this patch alone does not reduce the transferred data during cloning any smaller if you are using the "$1" repository over git native transport (including a local repository), because the current clone-pack does not look at existing refs (it was written assuming that there is _nothing_ in the cloned repository at the beginning). That needs a separate enhancements. Maybe it would be a good idea to deprecate clone-pack altogether, use fetch-pack -k, and implement the "copy upstream refs to our refs" logic in git-clone.sh. We need to do something like that if/when we are switching to use $GIT_DIR/refs/remotes/ to store tracking branches outside refs/heads anyway. The rsync transport has been deprecated for some time, and it does not handle alternates correctly anyway, so this patch does not have any impact on that. But if you are going to "$1" over http transport, this patch would help because we stash away the existing refs obtained from the reference repository under $GIT_DIR/refs/reference-tmp while we run the fetch. --- diff --git a/git-clone.sh b/git-clone.sh index 4ed861d..73fb03c 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -9,7 +9,7 @@ unset CDPATH usage() { - echo >&2 "Usage: $0 [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]" + echo >&2 "Usage: $0 [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]" exit 1 } @@ -56,6 +56,7 @@ upload_pack= bare= origin=origin origin_override= +reference= while case "$#,$1" in 0,*) break ;; @@ -68,6 +69,11 @@ while *,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared) local_shared=yes; use_local=yes ;; *,-q|*,--quiet) quiet=-q ;; + *,--reference=*) + reference=`expr "$1" : '-[^=]*=\(.*\)'` ;; + *,--reference) + case "$#" in 1) usage ;; esac + reference="$1" ;; 1,-o) usage;; *,-o) git-check-ref-format "$2" || { @@ -130,6 +136,23 @@ yes) GIT_DIR="$D/.git" ;; esac +# If given a reference we would first add that one; it has to name a +# local repository that resembles the one being cloned. +if test -d "$reference" +then + reference=$(cd "$reference" && pwd) + if test -d "$reference/.git/objects" + then + reference="$reference/.git" + fi + echo "$reference/objects" >"$GIT_DIR/objects/info/alternates" + # Pretend we know about these heads - clone-pack does not + # honor them currently, but that can be rectified later. + mkdir "$GIT_DIR/refs/reference-tmp" + (cd "$reference" && tar cf - refs) | + (cd "$GIT_DIR/refs/reference-tmp" && tar xf -) +fi + # We do local magic only when the user tells us to. case "$local,$use_local" in yes,yes) @@ -229,6 +252,7 @@ yes,yes) esac cd "$D" || exit +test -d "$GIT_DIR/refs/reference-tmp" && rm -fr "$GIT_DIR/refs/reference-tmp" if test -f "$GIT_DIR/HEAD" && test -z "$bare" then ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-19 23:18 ` Junio C Hamano @ 2006-03-20 0:32 ` James Cloos 2006-03-20 1:55 ` Junio C Hamano 0 siblings, 1 reply; 22+ messages in thread From: James Cloos @ 2006-03-20 0:32 UTC (permalink / raw) To: Junio C Hamano; +Cc: git >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes: Junio> "The same repo as this script" is a very poor way to define what Junio> you really want. I don't think so. Getting the same values in files like FETCH_HEAD, ORIG_HEAD, branches/*, remotes/*, info/* et al is not obvious. Especially, eg, all of the same Push/Pull lines. Junio> What is "git-repack -a -d -s"? A typo. I of course meant -a -d -l. Junio> It might be worth adding a --reference flag to git-clone like Junio> this patch does. That is essentially what I tried (except only the name of the flag; I prefer your choice). I didn't include the reference-tmp logic, but otherwise it looks about the same. Junio> However, this patch alone does not reduce the transferred data Junio> during cloning any smaller if you are using the "$1" repository Junio> over git native transport (including a local repository), Junio> because the current clone-pack does not look at existing refs Exactly the wall I ran into. And I really only need it for git://. Junio> Maybe it would be a good idea to deprecate Junio> clone-pack altogether, use fetch-pack -k, and implement the Junio> "copy upstream refs to our refs" logic in git-clone.sh. We need Junio> to do something like that if/when we are switching to use Junio> $GIT_DIR/refs/remotes/ to store tracking branches outside Junio> refs/heads anyway. And it looks like you've shown me the door in that wall. I'll have to read up on fetch-pack as opposed to clone-pack. -JimC -- James H. Cloos, Jr. <cloos@jhcloos.com> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 0:32 ` James Cloos @ 2006-03-20 1:55 ` Junio C Hamano 2006-03-20 8:54 ` Junio C Hamano 0 siblings, 1 reply; 22+ messages in thread From: Junio C Hamano @ 2006-03-20 1:55 UTC (permalink / raw) To: James Cloos; +Cc: git James Cloos <cloos@jhcloos.com> writes: > Junio> Maybe it would be a good idea to deprecate > Junio> clone-pack altogether, use fetch-pack -k, and implement the > Junio> "copy upstream refs to our refs" logic in git-clone.sh. We need > Junio> to do something like that if/when we are switching to use > Junio> $GIT_DIR/refs/remotes/ to store tracking branches outside > Junio> refs/heads anyway. > > And it looks like you've shown me the door in that wall. I was going to write that myself, but unfortunately will be offline for the rest of the evening -- interrupted by a surprise visitor from India who is only visiting for a few days. So in case you are really in a rush, and in a mood to build on top of my WIP, here is one. * fetch-pack.c is modified so that you can say: git fetch-pack --all -k $1 to get the list of "git ls-remote $1" equivalent while fetching everything from the remote. * Change git-clone.sh to use git-fetch-pack --all -k instead of git-clone-pack; the output from fetch-pack is munged further by a script that implements "copy the refs to the same location while figuring out where the HEAD is". The latter part in my WIP is incomplete so --use-separate-remote option probably would not work right now. --- diff --git a/fetch-pack.c b/fetch-pack.c index 535de10..2d0a626 100644 --- a/fetch-pack.c +++ b/fetch-pack.c @@ -7,8 +7,9 @@ static int keep_pack; static int quiet; static int verbose; +static int fetch_all; static const char fetch_pack_usage[] = -"git-fetch-pack [-q] [-v] [-k] [--thin] [--exec=upload-pack] [host:]directory <refs>..."; +"git-fetch-pack [--all] [-q] [-v] [-k] [--thin] [--exec=upload-pack] [host:]directory <refs>..."; static const char *exec = "git-upload-pack"; #define COMPLETE (1U << 0) @@ -266,8 +267,9 @@ static void filter_refs(struct ref **ref for (prev = NULL, current = *refs; current; current = next) { next = current->next; if ((!memcmp(current->name, "refs/", 5) && - check_ref_format(current->name + 5)) || - !path_match(current->name, nr_match, match)) { + check_ref_format(current->name + 5)) || + (!fetch_all && + !path_match(current->name, nr_match, match))) { if (prev == NULL) *refs = next; else @@ -426,6 +428,10 @@ int main(int argc, char **argv) use_thin_pack = 1; continue; } + if (!strcmp("--all", arg)) { + fetch_all = 1; + continue; + } if (!strcmp("-v", arg)) { verbose = 1; continue; diff --git a/git-clone.sh b/git-clone.sh index 4ed861d..718029b 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -9,7 +9,7 @@ unset CDPATH usage() { - echo >&2 "Usage: $0 [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]" + echo >&2 "Usage: $0 [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]" exit 1 } @@ -40,22 +40,74 @@ Perhaps git-update-server-info needs to do name=`expr "$refname" : 'refs/\(.*\)'` && case "$name" in - *^*) ;; - *) - git-http-fetch -v -a -w "$name" "$name" "$1/" || exit 1 + *^*) continue;; esac + if test -n "$use_separate_remote" && + branch_name=`expr "$name" : 'heads/\(.*\)'` + then + tname="remotes/$branch_name" + else + tname=$name + fi + git-http-fetch -v -a -w "$tname" "$name" "$1/" || exit 1 done <"$clone_tmp/refs" rm -fr "$clone_tmp" } +# A Perl script to read git-fetch -k output and store the +# remote branches. +copy_refs=' +use File::Path qw(mkpath); +my $refs_file = $ARGV[0]; +my $use_separate_remote = $ARGV[1]; +my $git_dir = $ARGV[2]; + +my $branch_top = ($use_separate_remote ? "heads" : "remotes"); +my $tag_top = "tags"; +my $head = undef; + +sub store { + my ($sha1, $name, $top) = @_; + $name = "$git_dir/refs/$top/$name"; + mkpath(dirname($name)); + open O, ">", "$name"; + print O "$sha1\n"; + close O; +} + +open FH, "<", $refs_file; +while (<FH>) { + my ($sha1, $name) = /^([0-9a-f]{40}) (.*)$/; + if ($name eq "HEAD") { + $head = $sha1; + next; + } + if ($name =~ s/^refs\/heads\//) { + if (!defined $head && $name eq "master") { + $head = $sha1; + } + store_branch($sha1, $name, $branch_top); + next; + } + if ($name =~ s/^refs\/tags\//) { + store_tag($sha1, $name, $tag_top); + next; + } +} +close FH; +' + + quiet= use_local=no local_shared=no no_checkout= upload_pack= bare= +reference= origin=origin origin_override= +use_separate_remote= while case "$#,$1" in 0,*) break ;; @@ -68,7 +120,14 @@ while *,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared) local_shared=yes; use_local=yes ;; *,-q|*,--quiet) quiet=-q ;; + *,--use-separate-remote) + use_separate_remote=t ;; 1,-o) usage;; + 1,--reference) usage ;; + *,--reference) + shift; reference="$2" ;; + *,--reference=*) + reference=`expr "$1" : '--reference=\(.*\)'` ;; *,-o) git-check-ref-format "$2" || { echo >&2 "'$2' is not suitable for a branch name" @@ -130,6 +189,26 @@ yes) GIT_DIR="$D/.git" ;; esac +if -n "$reference" +then + if test -d "$reference + then + if test -d "$reference/.git/objects" + then + reference="$reference/.git" + fi + reference=(cd "$reference" && pwd) + echo "$reference/objects" >"$GIT_DIR/objects/info/alternates" + (cd "$reference" && tar cf - refs) | + (cd "$GIT_DIR/refs && + mkdir reference-tmp && + cd reference-tmp && + tar xf -) + else + echo >&2 "$reference: not a local directory." && usage + fi +fi + # We do local magic only when the user tells us to. case "$local,$use_local" in yes,yes) @@ -217,17 +296,22 @@ yes,yes) ;; *) cd "$D" && case "$upload_pack" in - '') git-clone-pack $quiet "$repo" ;; - *) git-clone-pack $quiet "$upload_pack" "$repo" ;; - esac || { + '') git-fetch-pack -k $quiet "$repo" ;; + *) git-fetch-pack -k $quiet "$upload_pack" "$repo" ;; + esac >"$GIT_DIR/FETCH_HEAD" || { echo >&2 "clone-pack from '$repo' failed." exit 1 } + # Now figure out where the remote HEAD points at. + perl -e "$copy_refs" "$GIT_DIR/FETCH_HEAD" \ + "$use_separate_remote" "$GIT_DIR" ;; esac ;; esac +test -d "$GIT_DIR/refs/reference-tmp" && rm -fr "$GIT_DIR/refs/reference-tmp" + cd "$D" || exit if test -f "$GIT_DIR/HEAD" && test -z "$bare" ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 1:55 ` Junio C Hamano @ 2006-03-20 8:54 ` Junio C Hamano 2006-03-20 15:18 ` Petr Baudis 2006-03-20 16:30 ` Josef Weidendorfer 0 siblings, 2 replies; 22+ messages in thread From: Junio C Hamano @ 2006-03-20 8:54 UTC (permalink / raw) To: James Cloos; +Cc: git Junio C Hamano <junkio@cox.net> writes: > So in case you are really in a rush, and in a mood to build on > top of my WIP, here is one. And this is an replacement, which actually has seen some testing. I'll place this in the "next" branch tonight. Further testing is appreciated. -- >8 -- [PATCH] revamp git-clone. This does two things. * A new flag --reference can be used to name a local repository that is to be used as an alternate. This is in response to an inquiry by James Cloos in the message on the list <m3r74ykue7.fsf@lugabout.cloos.reno.nv.us>. * A new flag --use-separate-remote stops contaminating local branch namespace by upstream branch names. The upstream branch heads are copied in .git/refs/remotes/ instead of .git/refs/heads/ and .git/remotes/origin file is set up to reflect this as well. It requires to have fetch/pull update to understand .git/refs/remotes by Eric Wong to further update the repository cloned this way. For the former change, git-fetch-pack is taught a new flag --all to fetch from all the remote heads. Nobody uses the git-clone-pack with this change, so we could deprecate the command, but removal of the command will be left to a separate round. Signed-off-by: Junio C Hamano <junkio@cox.net> --- fetch-pack.c | 18 ++++-- git-clone.sh | 184 ++++++++++++++++++++++++++++++++++++++++++++++++---------- 2 files changed, 166 insertions(+), 36 deletions(-) dfeff66ed9a3931d60f3cd600ad8c14b5cc3d9e5 diff --git a/fetch-pack.c b/fetch-pack.c index 535de10..a3bcad0 100644 --- a/fetch-pack.c +++ b/fetch-pack.c @@ -7,8 +7,9 @@ static int keep_pack; static int quiet; static int verbose; +static int fetch_all; static const char fetch_pack_usage[] = -"git-fetch-pack [-q] [-v] [-k] [--thin] [--exec=upload-pack] [host:]directory <refs>..."; +"git-fetch-pack [--all] [-q] [-v] [-k] [--thin] [--exec=upload-pack] [host:]directory <refs>..."; static const char *exec = "git-upload-pack"; #define COMPLETE (1U << 0) @@ -266,8 +267,9 @@ static void filter_refs(struct ref **ref for (prev = NULL, current = *refs; current; current = next) { next = current->next; if ((!memcmp(current->name, "refs/", 5) && - check_ref_format(current->name + 5)) || - !path_match(current->name, nr_match, match)) { + check_ref_format(current->name + 5)) || + (!fetch_all && + !path_match(current->name, nr_match, match))) { if (prev == NULL) *refs = next; else @@ -376,7 +378,11 @@ static int fetch_pack(int fd[2], int nr_ goto all_done; } if (find_common(fd, sha1, ref) < 0) - fprintf(stderr, "warning: no common commits\n"); + if (!keep_pack) + /* When cloning, it is not unusual to have + * no common commit. + */ + fprintf(stderr, "warning: no common commits\n"); if (keep_pack) status = receive_keep_pack(fd, "git-fetch-pack", quiet); @@ -426,6 +432,10 @@ int main(int argc, char **argv) use_thin_pack = 1; continue; } + if (!strcmp("--all", arg)) { + fetch_all = 1; + continue; + } if (!strcmp("-v", arg)) { verbose = 1; continue; diff --git a/git-clone.sh b/git-clone.sh index 4ed861d..9db678b 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -9,7 +9,7 @@ unset CDPATH usage() { - echo >&2 "Usage: $0 [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]" + echo >&2 "Usage: $0 [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]" exit 1 } @@ -40,13 +40,61 @@ Perhaps git-update-server-info needs to do name=`expr "$refname" : 'refs/\(.*\)'` && case "$name" in - *^*) ;; - *) - git-http-fetch -v -a -w "$name" "$name" "$1/" || exit 1 + *^*) continue;; esac + if test -n "$use_separate_remote" && + branch_name=`expr "$name" : 'heads/\(.*\)'` + then + tname="remotes/$branch_name" + else + tname=$name + fi + git-http-fetch -v -a -w "$tname" "$name" "$1/" || exit 1 done <"$clone_tmp/refs" rm -fr "$clone_tmp" + http_fetch "$1/HEAD" "$GIT_DIR/REMOTE_HEAD" +} + +# Read git-fetch-pack -k output and store the remote branches. +copy_refs=' +use File::Path qw(mkpath); +use File::Basename qw(dirname); +my $git_dir = $ARGV[0]; +my $use_separate_remote = $ARGV[1]; + +my $branch_top = ($use_separate_remote ? "remotes" : "heads"); +my $tag_top = "tags"; + +sub store { + my ($sha1, $name, $top) = @_; + $name = "$git_dir/refs/$top/$name"; + mkpath(dirname($name)); + open O, ">", "$name"; + print O "$sha1\n"; + close O; +} + +open FH, "<", "$git_dir/CLONE_HEAD"; +while (<FH>) { + my ($sha1, $name) = /^([0-9a-f]{40})\s(.*)$/; + next if ($name =~ /\^\173/); + if ($name eq "HEAD") { + open O, ">", "$git_dir/REMOTE_HEAD"; + print O "$sha1\n"; + close O; + next; + } + if ($name =~ s/^refs\/heads\///) { + store($sha1, $name, $branch_top); + next; + } + if ($name =~ s/^refs\/tags\///) { + store($sha1, $name, $tag_top); + next; + } } +close FH; +' quiet= use_local=no @@ -54,8 +102,10 @@ local_shared=no no_checkout= upload_pack= bare= -origin=origin +reference= +origin= origin_override= +use_separate_remote= while case "$#,$1" in 0,*) break ;; @@ -68,7 +118,14 @@ while *,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared) local_shared=yes; use_local=yes ;; *,-q|*,--quiet) quiet=-q ;; + *,--use-separate-remote) + use_separate_remote=t ;; 1,-o) usage;; + 1,--reference) usage ;; + *,--reference) + shift; reference="$1" ;; + *,--reference=*) + reference=`expr "$1" : '--reference=\(.*\)'` ;; *,-o) git-check-ref-format "$2" || { echo >&2 "'$2' is not suitable for a branch name" @@ -100,9 +157,24 @@ then echo >&2 '--bare and -o $origin options are incompatible.' exit 1 fi + if test t = "$use_separate_remote" + then + echo >&2 '--bare and --use-separate-remote options are incompatible.' + exit 1 + fi no_checkout=yes fi +if test -z "$origin_override$origin" +then + if test -n "$use_separate_remote" + then + origin=remotes/master + else + origin=heads/origin + fi +fi + # Turn the source into an absolute path if # it is local repo="$1" @@ -130,6 +202,28 @@ yes) GIT_DIR="$D/.git" ;; esac +if test -n "$reference" +then + if test -d "$reference" + then + if test -d "$reference/.git/objects" + then + reference="$reference/.git" + fi + reference=$(cd "$reference" && pwd) + echo "$reference/objects" >"$GIT_DIR/objects/info/alternates" + (cd "$reference" && tar cf - refs) | + (cd "$GIT_DIR/refs" && + mkdir reference-tmp && + cd reference-tmp && + tar xf -) + else + echo >&2 "$reference: not a local directory." && usage + fi +fi + +rm -f "$GIT_DIR/CLONE_HEAD" + # We do local magic only when the user tells us to. case "$local,$use_local" in yes,yes) @@ -165,24 +259,14 @@ yes,yes) } >"$GIT_DIR/objects/info/alternates" ;; esac - - # Make a duplicate of refs and HEAD pointer - HEAD= - if test -f "$repo/HEAD" - then - HEAD=HEAD - fi - (cd "$repo" && tar cf - refs $HEAD) | - (cd "$GIT_DIR" && tar xf -) || exit 1 + git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" ;; *) case "$repo" in rsync://*) rsync $quiet -av --ignore-existing \ - --exclude info "$repo/objects/" "$GIT_DIR/objects/" && - rsync $quiet -av --ignore-existing \ - --exclude info "$repo/refs/" "$GIT_DIR/refs/" || exit - + --exclude info "$repo/objects/" "$GIT_DIR/objects/" || + exit # 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. @@ -205,6 +289,7 @@ yes,yes) done rm -f "$GIT_DIR/TMP_ALT" fi + git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" ;; http://*) if test -z "@@NO_CURL@@" @@ -217,37 +302,71 @@ yes,yes) ;; *) cd "$D" && case "$upload_pack" in - '') git-clone-pack $quiet "$repo" ;; - *) git-clone-pack $quiet "$upload_pack" "$repo" ;; - esac || { - echo >&2 "clone-pack from '$repo' failed." + '') git-fetch-pack --all -k $quiet "$repo" ;; + *) git-fetch-pack --all -k $quiet "$upload_pack" "$repo" ;; + esac >"$GIT_DIR/CLONE_HEAD" || { + echo >&2 "fetch-pack from '$repo' failed." exit 1 } ;; esac ;; esac +test -d "$GIT_DIR/refs/reference-tmp" && rm -fr "$GIT_DIR/refs/reference-tmp" + +if test -f "$GIT_DIR/CLONE_HEAD" +then + # Figure out where the remote HEAD points at. + perl -e "$copy_refs" "$GIT_DIR" "$use_separate_remote" +fi cd "$D" || exit -if test -f "$GIT_DIR/HEAD" && test -z "$bare" +if test -z "$bare" && test -f "$GIT_DIR/REMOTE_HEAD" then - head_points_at=`git-symbolic-ref HEAD` + head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"` + # Figure out which remote branch HEAD points at. + case "$use_separate_remote" in + '') remote_top=refs/heads ;; + *) remote_top=refs/remotes ;; + esac + head_points_at=$( + ( + echo "master" + cd "$GIT_DIR/$remote_top" && + find . -type f -print | sed -e 's/^\.\///' + ) | ( + done=f + while read name + do + test t = $done && continue + branch_tip=`cat "$GIT_DIR/$remote_top/$name"` + if test "$head_sha1" = "$branch_tip" + then + echo "$name" + done=t + fi + done + ) + ) case "$head_points_at" in - refs/heads/*) - head_points_at=`expr "$head_points_at" : 'refs/heads/\(.*\)'` + ?*) mkdir -p "$GIT_DIR/remotes" && echo >"$GIT_DIR/remotes/origin" \ "URL: $repo -Pull: $head_points_at:$origin" && - git-update-ref "refs/heads/$origin" $(git-rev-parse HEAD) && - (cd "$GIT_DIR" && find "refs/heads" -type f -print) | +Pull: refs/heads/$head_points_at:refs/$origin" && + case "$use_separate_remote" in + t) git-update-ref HEAD "$head_sha1" ;; + *) git-update-ref "refs/$origin" $(git-rev-parse HEAD) + esac && + (cd "$GIT_DIR" && find "$remote_top" -type f -print) | while read ref do - head=`expr "$ref" : 'refs/heads/\(.*\)'` && - test "$head_points_at" = "$head" || + head=`expr "$ref" : 'refs/\(.*\)'` && + name=`expr "$ref" : 'refs/[^\/]*/\(.*\)'` && + test "$head_points_at" = "$name" || test "$origin" = "$head" || - echo "Pull: ${head}:${head}" + echo "Pull: refs/heads/${name}:$remote_top/${name}" done >>"$GIT_DIR/remotes/origin" esac @@ -256,6 +375,7 @@ Pull: $head_points_at:$origin" && git-read-tree -m -u -v HEAD HEAD esac fi +rm -f "$GIT_DIR/CLONE_HEAD" "$GIT_DIR/REMOTE_HEAD" trap - exit -- 1.2.4.gb7986 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 8:54 ` Junio C Hamano @ 2006-03-20 15:18 ` Petr Baudis 2006-03-20 21:39 ` Junio C Hamano 2006-03-20 16:30 ` Josef Weidendorfer 1 sibling, 1 reply; 22+ messages in thread From: Petr Baudis @ 2006-03-20 15:18 UTC (permalink / raw) To: Junio C Hamano; +Cc: James Cloos, git Dear diary, on Mon, Mar 20, 2006 at 09:54:03AM CET, I got a letter where Junio C Hamano <junkio@cox.net> said that... > * A new flag --use-separate-remote stops contaminating local > branch namespace by upstream branch names. The upstream > branch heads are copied in .git/refs/remotes/ instead of > .git/refs/heads/ and .git/remotes/origin file is set up to > reflect this as well. It requires to have fetch/pull update > to understand .git/refs/remotes by Eric Wong to further > update the repository cloned this way. I think this sucks the way it is, because you still have only a single namespace for remotes (still quite a huge improvement to the current git situation), but you can have many upstreams. So it would be a quite more reasonable to have: .git/refs/remotes/<remotename>/<headname> This is also how I would like to do it for cg-clone -a (which I planned to implement the last weekend... well... ;). Actually, I think I will stay in .git/refs/heads/ at least for now until git versions with .git/refs/remotes/ in the refs search path will be released. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Right now I am having amnesia and deja-vu at the same time. I think I have forgotten this before. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 15:18 ` Petr Baudis @ 2006-03-20 21:39 ` Junio C Hamano 2006-03-20 22:41 ` Petr Baudis 0 siblings, 1 reply; 22+ messages in thread From: Junio C Hamano @ 2006-03-20 21:39 UTC (permalink / raw) To: Petr Baudis; +Cc: git Petr Baudis <pasky@suse.cz> writes: > I think this sucks the way it is, because you still have only a single > namespace for remotes (still quite a huge improvement to the current git > situation), but you can have many upstreams. Come on, give me a break. You are commenting on the initial 'git-clone' and specifically on one of its optional feature. What multiple upstreams? The whole point of what git-clone does on top of making a straight clone of the remote is to give you a reasonable starting point. The traditional "master" -> "origin" mapping is good for cloning a typical single-head repository. If your upsteram has more branches, --use-separate-remote would help you to start your branch namespace uncluttered. If you want to go fancier after the initial clone to "cg-add-branch" more upstreams, you can implement a customized editor, even a graphical one if you want, that inspects $GIT_DIR/[branches,remotes} _and_ $GIT_DIR/{heads,remotes}, shows the current status, and lets you edit the contents of a $GIT_DIR/remotes/foobar _while_ making matching changes to what are under $GIT_DIR/{heads,remotes}. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 21:39 ` Junio C Hamano @ 2006-03-20 22:41 ` Petr Baudis 2006-03-20 23:07 ` Junio C Hamano 0 siblings, 1 reply; 22+ messages in thread From: Petr Baudis @ 2006-03-20 22:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Dear diary, on Mon, Mar 20, 2006 at 10:39:41PM CET, I got a letter where Junio C Hamano <junkio@cox.net> said that... > You are commenting on the initial 'git-clone' and specifically > on one of its optional feature. What multiple upstreams? > > The whole point of what git-clone does on top of making a > straight clone of the remote is to give you a reasonable > starting point. The traditional "master" -> "origin" mapping is > good for cloning a typical single-head repository. If your > upsteram has more branches, --use-separate-remote would help you > to start your branch namespace uncluttered. Yes, but I just see no connecting with a "starting point" whatsoever - why should this be inherent to initial clone? I can see no greater chance that I will want all the branches than when I want to fetch from another repository later (especially in a truly distributed environment). So, it doesn't make sense to me to limit this feature only to the initial clone case - I want to be able to reasonably "fetch all branches" of any repository I wish. Without massive namespace clashes, the reasonable way is to just have a separate directory in .git/refs/remotes/ for each repository (and it's my understanding that this was the original proposal as well). Then you can make a simple change that if a refname matches a directory in refs/remotes/, you rewrite it as refs/remotes/<refname>/master. This makes 'origin' work seamlessly in a natural way and a lot more elegantly than if you make up an artifical rule like "if the remote's branch is master, save it as origin, but save all the other branches verbatim". -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Right now I am having amnesia and deja-vu at the same time. I think I have forgotten this before. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 22:41 ` Petr Baudis @ 2006-03-20 23:07 ` Junio C Hamano 0 siblings, 0 replies; 22+ messages in thread From: Junio C Hamano @ 2006-03-20 23:07 UTC (permalink / raw) To: Petr Baudis; +Cc: git Petr Baudis <pasky@suse.cz> writes: > Then you can make a simple change that if a refname matches a directory > in refs/remotes/, you rewrite it as refs/remotes/<refname>/master. This > makes 'origin' work seamlessly in a natural way and a lot more elegantly > than if you make up an artifical rule like "if the remote's branch is > master, save it as origin, but save all the other branches verbatim". The "origin" rename applies only to the traditional one. Separate remote stuff stores master in remotes/master. At least that is the way I remember I designed it to work. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 8:54 ` Junio C Hamano 2006-03-20 15:18 ` Petr Baudis @ 2006-03-20 16:30 ` Josef Weidendorfer 2006-03-20 23:04 ` Junio C Hamano 2006-03-21 8:28 ` Junio C Hamano 1 sibling, 2 replies; 22+ messages in thread From: Josef Weidendorfer @ 2006-03-20 16:30 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Monday 20 March 2006 09:54, you wrote: > * A new flag --use-separate-remote stops contaminating local > branch namespace by upstream branch names. The upstream > branch heads are copied in .git/refs/remotes/ instead of Shouldn't this be .git/refs/remotes/origin/? Ie. different namespaces for different remotes? Linus wanted to still be able to say "origin" which automatically would map to "remotes/origin/master", where the name of the remote branch (here "master") is the first mentioned in the Pull line of the .git/remotes file in eg. git diff origin..master I am not sure whether we really want "take first refspec mentioned on Pull line", as there can be multiple tracked remote branches with their own local developments... Ie. I want to be able to specify: "The local development branch X is based on the following remote branch Y , which is tracked locally as Z.". This way, you also could warn/prohobit accidential nonsense merges because of wrong use of "git-pull". Josef ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 16:30 ` Josef Weidendorfer @ 2006-03-20 23:04 ` Junio C Hamano 2006-03-20 23:21 ` Petr Baudis 2006-03-21 0:26 ` Josef Weidendorfer 2006-03-21 8:28 ` Junio C Hamano 1 sibling, 2 replies; 22+ messages in thread From: Junio C Hamano @ 2006-03-20 23:04 UTC (permalink / raw) To: Josef Weidendorfer; +Cc: git Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes: > On Monday 20 March 2006 09:54, you wrote: >> * A new flag --use-separate-remote stops contaminating local >> branch namespace by upstream branch names. The upstream >> branch heads are copied in .git/refs/remotes/ instead of > > Shouldn't this be .git/refs/remotes/origin/? > Ie. different namespaces for different remotes? > > Linus wanted to still be able to say "origin" which automatically > would map to "remotes/origin/master", where the name of the remote I do not remember that, but even if he said something similar to that, I suspect it would not be "map remotes/origin/master to origin", but "origin could mean remotes/origin when origin is the unique tail-name anywhere under refs/". I think what is reasonable is something like this: - If you start from a repository cloned in the traditional way, the upstream "master" is kept track of with your "origin", so "diff origin master" would be "my changes on top of the upstream". - If your repository was cloned with --use-separate-remote, the upstream "master" is refs/remotes/master, so the same diff can be had with "diff remotes/master master". - Regardless of how you started your cloned repository, with an $GIT_DIR/{remotes,refs/heads,refs/remotes} editor I hinted in a separate message, you can rearrange things to organize the refs/ hierarchy any way you want. - You could for example arrange to track my "master" as refs/heads/origin and all the other branch heads under refs/remotes/junkio/ (or not even track my other branches if you are not interested). Then the same diff can be had with "diff origin master". - You could for example arrange to track all my branches in refs/remotes/junkio/, and if git-pasky were still alive, Pasky's branches in refs/remotes/pasky. If we had a "take the unique tail-name anywhere under refs/" logic, the same diff can be had with "diff junkio/master master". So I think two things that would be nice to have on top of what we have are (1) the said "remotes-and-refs editor" [*1*], and (2) a change to sha1_name.c to look for places other than built-in tags/ and heads/ under refs/ to find a unique tail-match. Since I do not do Porcelain, (2) would obviously be the next thing for me to work on on this topic. I should also address "Ouch I did not realize I have given the same name to a tag and a branch" warning issue while doing so. [Footnote] *1* ... which currently I do not plan to do myself unless I have absolutely nothing else to do and really bored. A sound of huge hint dropping ;-). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 23:04 ` Junio C Hamano @ 2006-03-20 23:21 ` Petr Baudis 2006-03-20 23:49 ` Junio C Hamano 2006-03-21 0:26 ` Josef Weidendorfer 1 sibling, 1 reply; 22+ messages in thread From: Petr Baudis @ 2006-03-20 23:21 UTC (permalink / raw) To: Junio C Hamano; +Cc: Josef Weidendorfer, git Dear diary, on Tue, Mar 21, 2006 at 12:04:34AM CET, I got a letter where Junio C Hamano <junkio@cox.net> said that... > I think what is reasonable is something like this: <insert all of the arguments in my other mail here ;> > - If your repository was cloned with --use-separate-remote, the > upstream "master" is refs/remotes/master, so the same diff > can be had with "diff remotes/master master". Which is ugly. There is no reason why you couldn't go on using 'origin' which is shorter and we can usually still unambiguously decide what did you mean (unless you have a local head/tag 'origin' _and_ a remote named 'origin' at the same time). > - Regardless of how you started your cloned repository, with an > $GIT_DIR/{remotes,refs/heads,refs/remotes} editor I hinted in > a separate message, you can rearrange things to organize the > refs/ hierarchy any way you want. Yes, but that makes no sense to do when you usually need this only in some very special cases (and then you ought to be able to set up the weird thing yourself), while we can do the doubtlessly right thing in the general case, WITHOUT confusing the user, WHILE keeping things tidy and easy to use (and without excessive typing). In fact, you described it yourself: > - You could for example arrange to track all my branches in > refs/remotes/junkio/, and if git-pasky were still alive, > Pasky's branches in refs/remotes/pasky. If we had a "take > the unique tail-name anywhere under refs/" logic, the same > diff can be had with "diff junkio/master master". Except that you can just name the refs/remotes/directory the same way you name the remote repository identifier (be it a Git-style remote or Cogito's remote branch). I still don't get what's wrong on what I'm proposing. I'm not seeing the disadvantages, if there are any. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Right now I am having amnesia and deja-vu at the same time. I think I have forgotten this before. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 23:21 ` Petr Baudis @ 2006-03-20 23:49 ` Junio C Hamano 2006-03-21 8:19 ` Andreas Ericsson 0 siblings, 1 reply; 22+ messages in thread From: Junio C Hamano @ 2006-03-20 23:49 UTC (permalink / raw) To: Petr Baudis; +Cc: Josef Weidendorfer, git Petr Baudis <pasky@suse.cz> writes: > I still don't get what's wrong on what I'm proposing. I'm not seeing the > disadvantages, if there are any. The only thing I think there is is that I do not get what you are proposing ;-), since I am not paying full attention while at day-job. If you are proposing to root --use-separate-remote not at refs/remotes but refs/remotes/origin/, I think it makes kind of sense. It would make tons of sense _if_ dealing more than one remote repository is the norm, but otherwise you would have an extra level of directory refs/remotes which almost always have only one subdirectory 'origin' and nothing else, which is pointless. I am not sure if you are also advocating to map (somehow) origin to remotes/origin/master (or whatever branch remote's HEAD points at), but if so I am not quite sure what its semantics would be. Which remote branch would you pick (that would not necessarily be "master") and where are you going to record that and when. It all sounds to me complicating things unnecessarily. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 23:49 ` Junio C Hamano @ 2006-03-21 8:19 ` Andreas Ericsson 2006-03-21 8:42 ` Junio C Hamano 0 siblings, 1 reply; 22+ messages in thread From: Andreas Ericsson @ 2006-03-21 8:19 UTC (permalink / raw) To: Junio C Hamano; +Cc: Petr Baudis, Josef Weidendorfer, git Junio C Hamano wrote: > Petr Baudis <pasky@suse.cz> writes: > > >>I still don't get what's wrong on what I'm proposing. I'm not seeing the >>disadvantages, if there are any. > > > The only thing I think there is is that I do not get what you > are proposing ;-), since I am not paying full attention while at > day-job. > > If you are proposing to root --use-separate-remote not at > refs/remotes but refs/remotes/origin/, I think it makes kind of > sense. It would make tons of sense _if_ dealing more than one > remote repository is the norm, but otherwise you would have an > extra level of directory refs/remotes which almost always have > only one subdirectory 'origin' and nothing else, which is > pointless. > afaiu, this is exactly what Pasky's proposing, and I agree. We could then teach 'git diff origin master' to mean 'origin/master' *if* no other tag/branch is found in the lookup order. I think it makes sense to do searching like this, for a ref named foo (current order, with .git/, .git/refs/, etc...) .git/refs/remotes/foo .git/refs/remotes/foo/master That way the only extra dwimery would be to add "remotes" after "heads" under .git/refs and accept directory in .git/remotes/ as ref and tack on '/master' at the end of it as the last option to search. For a specific branch on an imported remote, one would have to say "jc/next". This means we still only handle 'master' specially so we don't introduce any new protected or special names. > I am not sure if you are also advocating to map (somehow) origin > to remotes/origin/master (or whatever branch remote's HEAD > points at), but if so I am not quite sure what its semantics > would be. Which remote branch would you pick (that would not > necessarily be "master") and where are you going to record that > and when. It all sounds to me complicating things > unnecessarily. > Not too much so, I think. I'll look into it tonight, although I'm not very familiar with the core stuff so possibly (/ hopefully) someone else will beat me to it. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-21 8:19 ` Andreas Ericsson @ 2006-03-21 8:42 ` Junio C Hamano 2006-03-21 9:19 ` Jeff King 0 siblings, 1 reply; 22+ messages in thread From: Junio C Hamano @ 2006-03-21 8:42 UTC (permalink / raw) To: Andreas Ericsson; +Cc: Petr Baudis, Josef Weidendorfer, git Andreas Ericsson <ae@op5.se> writes: > That way the only extra dwimery would be to add "remotes" after > "heads" under .git/refs and accept directory in .git/remotes/ as ref > and tack on '/master' at the end of it as the last option to > search. For a specific branch on an imported remote, one would have to > say "jc/next". This means we still only handle 'master' specially so > we don't introduce any new protected or special names. Two things that holding me back from doing what you suggested are (1) "master" is just a convention and indeed non-negligible number of kernel.org trees have "test" and "release" instead without "master"; (2) I'd really really really want to avoid teaching get_sha1_basic() C-level about .git/remotes/$origin file, even though that function is more of a UI level than the rest of the really core C-level routines. But if I were forced to choose between the above 2, I would probably pick defaulting to "master". The reason I would like to avoid .git/remotes/$origin is because it is designed to be Porcelainish thing. The underlying C-level git-fetch-pack never sees it; instead the information fed to C-level is prepared by the upper layer using that file. As far as I understand, Cogito does not understand it either, except that it ships with bash completion code that reads from filenames there. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-21 8:42 ` Junio C Hamano @ 2006-03-21 9:19 ` Jeff King 2006-03-21 9:45 ` Junio C Hamano 0 siblings, 1 reply; 22+ messages in thread From: Jeff King @ 2006-03-21 9:19 UTC (permalink / raw) To: git On Tue, Mar 21, 2006 at 12:42:02AM -0800, Junio C Hamano wrote: > The reason I would like to avoid .git/remotes/$origin is because > it is designed to be Porcelainish thing. The underlying C-level > git-fetch-pack never sees it; instead the information fed to > C-level is prepared by the upper layer using that file. As far > as I understand, Cogito does not understand it either, except > that it ships with bash completion code that reads from > filenames there. Then why not create .git/refs/remotes/$origin/HEAD at the time of clone (or later)? Then the core looks for: (current order, .git/refs, etc) .git/refs/remotes/foo .git/refs/remotes/foo/HEAD The porcelain can take care of managing the contents of HEAD. If there is no HEAD in the directory, then it cannot be looked up by 'foo' ('foo/remote-branch' must be used instead). -Peff ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-21 9:19 ` Jeff King @ 2006-03-21 9:45 ` Junio C Hamano 2006-03-21 11:29 ` Petr Baudis 0 siblings, 1 reply; 22+ messages in thread From: Junio C Hamano @ 2006-03-21 9:45 UTC (permalink / raw) To: Jeff King; +Cc: git Jeff King <peff@peff.net> writes: > Then why not create .git/refs/remotes/$origin/HEAD at the time of clone > (or later)? Then the core looks for: > (current order, .git/refs, etc) > .git/refs/remotes/foo > .git/refs/remotes/foo/HEAD > The porcelain can take care of managing the contents of HEAD. If there > is no HEAD in the directory, then it cannot be looked up by 'foo' > ('foo/remote-branch' must be used instead). Yup, earlier I mentioned that possibility, and it does not seem too painful. On top of the "next", here is what is needed. -- >8 -- [PATCH] get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD This implements the suggestion by Jeff King to use refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean the primary branch head of a tracked remote. clone needs to be told about this convention as well. Signed-off-by: Junio C Hamano <junkio@cox.net> --- sha1_name.c | 23 ++++++++++++----------- 1 files changed, 12 insertions(+), 11 deletions(-) c51d13692d4e451c755dd7da3521c5db395df192 diff --git a/sha1_name.c b/sha1_name.c index 74c479c..3adaec3 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -235,18 +235,21 @@ static int ambiguous_path(const char *pa static int get_sha1_basic(const char *str, int len, unsigned char *sha1) { - static const char *prefix[] = { - "", - "refs", - "refs/tags", - "refs/heads", - "refs/remotes", + static const char *fmt[] = { + "/%.*s", + "refs/%.*s", + "refs/tags/%.*s", + "refs/heads/%.*s", + "refs/remotes/%.*s", + "refs/remotes/%.*s/HEAD", NULL }; const char **p; const char *warning = "warning: refname '%.*s' is ambiguous.\n"; char *pathname; int already_found = 0; + unsigned char *this_result; + unsigned char sha1_from_ref[20]; if (len == 40 && !get_sha1_hex(str, sha1)) return 0; @@ -255,11 +258,9 @@ static int get_sha1_basic(const char *st if (ambiguous_path(str, len)) return -1; - for (p = prefix; *p; p++) { - unsigned char sha1_from_ref[20]; - unsigned char *this_result = - already_found ? sha1_from_ref : sha1; - pathname = git_path("%s/%.*s", *p, len, str); + for (p = fmt; *p; p++) { + this_result = already_found ? sha1_from_ref : sha1; + pathname = git_path(*p, len, str); if (!read_ref(pathname, this_result)) { if (warn_ambiguous_refs) { if (already_found && -- 1.2.4.gf1250 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-21 9:45 ` Junio C Hamano @ 2006-03-21 11:29 ` Petr Baudis 0 siblings, 0 replies; 22+ messages in thread From: Petr Baudis @ 2006-03-21 11:29 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeff King, git Dear diary, on Tue, Mar 21, 2006 at 10:45:12AM CET, I got a letter where Junio C Hamano <junkio@cox.net> said that... > Jeff King <peff@peff.net> writes: > > > Then why not create .git/refs/remotes/$origin/HEAD at the time of clone > > (or later)? Then the core looks for: > > (current order, .git/refs, etc) > > .git/refs/remotes/foo > > .git/refs/remotes/foo/HEAD > > The porcelain can take care of managing the contents of HEAD. If there > > is no HEAD in the directory, then it cannot be looked up by 'foo' > > ('foo/remote-branch' must be used instead). > > Yup, earlier I mentioned that possibility, and it does not seem > too painful. On top of the "next", here is what is needed. > > -- >8 -- > [PATCH] get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD > > This implements the suggestion by Jeff King to use > refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean > the primary branch head of a tracked remote. clone needs to be > told about this convention as well. > > Signed-off-by: Junio C Hamano <junkio@cox.net> Excellent, yes, that's what I've meant. I'm happy now. :) Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Right now I am having amnesia and deja-vu at the same time. I think I have forgotten this before. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 23:04 ` Junio C Hamano 2006-03-20 23:21 ` Petr Baudis @ 2006-03-21 0:26 ` Josef Weidendorfer 2006-03-21 0:57 ` Junio C Hamano 1 sibling, 1 reply; 22+ messages in thread From: Josef Weidendorfer @ 2006-03-21 0:26 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Tuesday 21 March 2006 00:04, you wrote: > > Linus wanted to still be able to say "origin" which automatically > > would map to "remotes/origin/master", where the name of the remote > > I do not remember that, See http://www.gelato.unsw.edu.au/archives/git/0603/17405.html I found it strange at first. But I think it is the right thing. > I think what is reasonable is something like this: > > - If you start from a repository cloned in the traditional > way, the upstream "master" is kept track of with your > "origin", so "diff origin master" would be "my changes on top > of the upstream". Yes. And it would be nice if the same would work with the new layout, assuming that there is no local "origin" branch, but a .git/remotes/origin file and .git/refs/remotes/origin directory. > - Regardless of how you started your cloned repository, with an > $GIT_DIR/{remotes,refs/heads,refs/remotes} editor I hinted in > a separate message, you can rearrange things to organize the > refs/ hierarchy any way you want. Yes. Still it would be nice to have a fixed convention here. Eg. gitk could decorate the namespace in a special way. Even if it is most of the time "origin" only. > [Footnote] > > *1* ... which currently I do not plan to do myself unless I have > absolutely nothing else to do and really bored. A sound of huge > hint dropping ;-). It should be as simple as (probably with quite some errors) ~/> cat git-rename-remote.sh mv .git/refs/remotes/$1 .git/refs/remotes/$2 sed -e "s|remotes/$1|remotes/$2" .git/remotes/$1 > .git/remotes/$2 rm .git/remotes/$1 If you allow more freedom regarding the use of refs/remotes, it gets more complicated both for the script and for the user to understand. Josef ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-21 0:26 ` Josef Weidendorfer @ 2006-03-21 0:57 ` Junio C Hamano 0 siblings, 0 replies; 22+ messages in thread From: Junio C Hamano @ 2006-03-21 0:57 UTC (permalink / raw) To: Josef Weidendorfer; +Cc: git Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes: >> I think what is reasonable is something like this: >> >> - If you start from a repository cloned in the traditional >> way, the upstream "master" is kept track of with your >> "origin", so "diff origin master" would be "my changes on top >> of the upstream". > > Yes. And it would be nice if the same would work with the new layout, > assuming that there is no local "origin" branch, but a .git/remotes/origin > file and .git/refs/remotes/origin directory. My primary aversion comes from that I'd rather avoid teaching the really core stuff about .git/remotes file, and the part that interprets refname is fairly a low-level part. We _could_ record refs/remotes/origin/HEAD that points at refs/remotes/origin/master (or some other branch) upon cloning, and if Pasky wants to do something similar upon fetching, that fetch command could do the same thing. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: efficient cloning 2006-03-20 16:30 ` Josef Weidendorfer 2006-03-20 23:04 ` Junio C Hamano @ 2006-03-21 8:28 ` Junio C Hamano 1 sibling, 0 replies; 22+ messages in thread From: Junio C Hamano @ 2006-03-21 8:28 UTC (permalink / raw) To: Josef Weidendorfer; +Cc: git, Petr Baudis Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes: > Shouldn't this be .git/refs/remotes/origin/? > Ie. different namespaces for different remotes? OK, here is a second try, that comes on top of the one from the last night. Together with another topic in the "next" branch, you can now do this: $ git clone --use-separate-remote --reference git.git \ git://git.kernel.org/pub/scm/git/git.git new.git $ cd new.git $ git branch * master $ git log --pretty=oneline master..origin/next | wc -l 72 What the last one shows is that sha1_basic() lets you omit refs/remotes; it does not let you say "origin" to mean "refs/remotes/origin/master", although I agree that abbreviation would be useful. As I am still not yet convinced that using what is in .git/remotes/origin is a good way to implement that shorthand, and would rather avoid reading .git/remotes/origin from the C level (even though sha1_basic() is not _that_ core but a lot closer to the UI, compared to other C level routines), I am leaving that part for later rounds. -- >8 -- [PATCH] revamp git-clone (take #2). This builds on top of the previous one. * --use-separate-remote uses .git/refs/remotes/$origin/ directory to keep track of the upstream branches. * The $origin above defaults to "origin" as usual, but the existing "-o $origin" option can be used to override it. I am not yet convinced if we should make "$origin" the synonym to "refs/remotes/$origin/$name" where $name is the primary branch name of $origin upstream, nor if so how we should decide which upstream branch is the primary one, but that is more or less orthogonal to what the clone does here. Signed-off-by: Junio C Hamano <junkio@cox.net> --- git-clone.sh | 50 +++++++++++++++++++++++++++++++------------------- 1 files changed, 31 insertions(+), 19 deletions(-) 47874d6d9a7f49ade6388df049597f03365961ca diff --git a/git-clone.sh b/git-clone.sh index 9db678b..3b54753 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -9,7 +9,7 @@ unset CDPATH usage() { - echo >&2 "Usage: $0 [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]" + echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]" exit 1 } @@ -61,8 +61,9 @@ use File::Path qw(mkpath); use File::Basename qw(dirname); my $git_dir = $ARGV[0]; my $use_separate_remote = $ARGV[1]; +my $origin = $ARGV[2]; -my $branch_top = ($use_separate_remote ? "remotes" : "heads"); +my $branch_top = ($use_separate_remote ? "remotes/$origin" : "heads"); my $tag_top = "tags"; sub store { @@ -127,7 +128,12 @@ while *,--reference=*) reference=`expr "$1" : '--reference=\(.*\)'` ;; *,-o) - git-check-ref-format "$2" || { + case "$2" in + */*) + echo >&2 "'$2' is not suitable for an origin name" + exit 1 + esac + git-check-ref-format "heads/$2" || { echo >&2 "'$2' is not suitable for a branch name" exit 1 } @@ -165,14 +171,9 @@ then no_checkout=yes fi -if test -z "$origin_override$origin" +if test -z "$origin" then - if test -n "$use_separate_remote" - then - origin=remotes/master - else - origin=heads/origin - fi + origin=origin fi # Turn the source into an absolute path if @@ -317,7 +318,7 @@ test -d "$GIT_DIR/refs/reference-tmp" && if test -f "$GIT_DIR/CLONE_HEAD" then # Figure out where the remote HEAD points at. - perl -e "$copy_refs" "$GIT_DIR" "$use_separate_remote" + perl -e "$copy_refs" "$GIT_DIR" "$use_separate_remote" "$origin" fi cd "$D" || exit @@ -328,8 +329,18 @@ then # Figure out which remote branch HEAD points at. case "$use_separate_remote" in '') remote_top=refs/heads ;; - *) remote_top=refs/remotes ;; + *) remote_top="refs/remotes/$origin" ;; esac + + # What to use to track the remote primary branch + if test -n "$use_separate_remote" + then + origin_tracking="remotes/$origin/master" + else + origin_tracking="heads/$origin" + fi + + # The name under $remote_top the remote HEAD seems to point at head_points_at=$( ( echo "master" @@ -349,25 +360,26 @@ then done ) ) + + # Write out remotes/$origin file. case "$head_points_at" in ?*) mkdir -p "$GIT_DIR/remotes" && - echo >"$GIT_DIR/remotes/origin" \ + echo >"$GIT_DIR/remotes/$origin" \ "URL: $repo -Pull: refs/heads/$head_points_at:refs/$origin" && +Pull: refs/heads/$head_points_at:refs/$origin_tracking" && case "$use_separate_remote" in t) git-update-ref HEAD "$head_sha1" ;; *) git-update-ref "refs/$origin" $(git-rev-parse HEAD) esac && - (cd "$GIT_DIR" && find "$remote_top" -type f -print) | - while read ref + (cd "$GIT_DIR/$remote_top" && find . -type f -print) | + while read dotslref do - head=`expr "$ref" : 'refs/\(.*\)'` && - name=`expr "$ref" : 'refs/[^\/]*/\(.*\)'` && + name=`expr "$dotslref" : './\(.*\)'` && test "$head_points_at" = "$name" || test "$origin" = "$head" || echo "Pull: refs/heads/${name}:$remote_top/${name}" - done >>"$GIT_DIR/remotes/origin" + done >>"$GIT_DIR/remotes/$origin" esac case "$no_checkout" in -- 1.2.4.ge2fc ^ permalink raw reply related [flat|nested] 22+ messages in thread
end of thread, other threads:[~2006-03-21 11:29 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-03-19 21:16 efficient cloning James Cloos 2006-03-19 22:31 ` Shawn Pearce 2006-03-19 23:18 ` Junio C Hamano 2006-03-20 0:32 ` James Cloos 2006-03-20 1:55 ` Junio C Hamano 2006-03-20 8:54 ` Junio C Hamano 2006-03-20 15:18 ` Petr Baudis 2006-03-20 21:39 ` Junio C Hamano 2006-03-20 22:41 ` Petr Baudis 2006-03-20 23:07 ` Junio C Hamano 2006-03-20 16:30 ` Josef Weidendorfer 2006-03-20 23:04 ` Junio C Hamano 2006-03-20 23:21 ` Petr Baudis 2006-03-20 23:49 ` Junio C Hamano 2006-03-21 8:19 ` Andreas Ericsson 2006-03-21 8:42 ` Junio C Hamano 2006-03-21 9:19 ` Jeff King 2006-03-21 9:45 ` Junio C Hamano 2006-03-21 11:29 ` Petr Baudis 2006-03-21 0:26 ` Josef Weidendorfer 2006-03-21 0:57 ` Junio C Hamano 2006-03-21 8:28 ` Junio C Hamano
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.