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]
[not found] ` <20060305223115.37c1a734.seanlkml@sympatico.ca>
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$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=junkio@cox$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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