From: Junio C Hamano <junkio@cox.net>
To: James Cloos <cloos@jhcloos.com>
Cc: git@vger.kernel.org
Subject: Re: efficient cloning
Date: Sun, 19 Mar 2006 15:18:49 -0800 [thread overview]
Message-ID: <7vu09um3ae.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: m3r74ykue7.fsf@lugabout.cloos.reno.nv.us
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
next prev parent reply other threads:[~2006-03-19 23:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-19 21:16 efficient cloning James Cloos
2006-03-19 22:31 ` Shawn Pearce
2006-03-19 23:18 ` Junio C Hamano [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vu09um3ae.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=cloos@jhcloos.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox