From: Shawn Pearce <spearce@spearce.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: git clone downloads objects that are in GIT_OBJECT_DIRECTORY
Date: Sun, 5 Mar 2006 21:57:02 -0500 [thread overview]
Message-ID: <20060306025702.GH25790@spearce.org> (raw)
In-Reply-To: <7vfylwcncn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Benjamin LaHaise <bcrl@kvack.org> wrote:
> >> Hi folks,
> >>
> >> Doing a fresh git clone git://some.git.url/ foo seems to download the
> >> entire remote repository even if all the objects are already stored in
> >> GIT_OBJECT_DIRECTORY=/home/bcrl/.git/object . Is this a known bug?
> >> At 100MB for a kernel, this takes a *long* time.
> >
> > I believe it is a known missing feature. :-) git-clone doesn't
> > prep HEAD to have some sort of starting point so the pull it uses
> > to download everything literally downloads everything as nothing
> > is in common.
>
> You would first 'clone -l -s' from your local repository and
> then clone into that from whatever remote, perhaps.
Yea but that's about as much fun as creating a bare repository
by hand. (Which I've been doing up until this thread prompted me
to read git-clone.sh and learn the existance of --bare.)
It might be nicer if the user could place a list of locally (here
locally being possibly remote but closer network-wise) available
repositories which should be considered as sources for faster
cloning. When cloning a remote repository git-clone would try to
examine each of the designated repositories to see if any of them
have commits in common with the remote; if so clone off that and
then pull from the remote, but designating the remote as `origin'.
This could be ugly if you have a large number of locally available
candidates or if the candidates are many (e.g. 1000s) commits
behind the remote being cloned. But it would save the user from
pulling down 100+MB of objects they already have while making it
very convient to establish a new repository+working directory based
on someone else's publically available repository.
Or we could just tell the user to create their own clone script,
e.g. kernel-clone:
#!/bin/sh
git-clone -l -n -s ~/kernel-base "$2" &&
cd "$2" &&
echo "URL: $1" >.git/remotes/origin &&
echo "Pull: master:origin" >>.git/remotes/origin &&
git-pull
But it would be better if it was more integrated, and somehow
slightly more automatic...
--
Shawn.
next prev parent reply other threads:[~2006-03-06 2:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-06 1:08 git clone downloads objects that are in GIT_OBJECT_DIRECTORY Benjamin LaHaise
2006-03-06 1:42 ` Shawn Pearce
2006-03-06 2:34 ` Junio C Hamano
2006-03-06 2:57 ` Shawn Pearce [this message]
2006-03-06 3:31 ` sean
2006-03-06 3:31 ` sean
2006-03-06 9:20 ` Johannes Schindelin
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=20060306025702.GH25790@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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 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.