size of git repository (was Re: [BUG] New Kernel Bugs)

[Willy Tarreau]

On Sun, Nov 18, 2007 at 03:56:11PM +0100, Ingo Molnar wrote:
> 
> * Pavel Machek <pavel at ucw.cz> wrote:
> 
> > On Tue 2007-11-13 12:50:08, Mark Lord wrote:
> > > Ingo Molnar wrote:
> > > >
> > > >for example git-bisect was godsent. I remember that 
> > > >years ago bisection of a bug was a very laborous task 
> > > >so that it was only used as a final, last-ditch 
> > > >approach for really nasty bugs. Today we can 
> > > >autonomouly bisect build bugs via a simple shell 
> > > >command around "git-bisect run", without any human 
> > > >interaction! This freed up testing resources 
> > > ..
> > > 
> > > It's only a godsend for the few people who happen to be 
> > > kernel developers
> > > and who happen to already use git.
> > > 
> > > It's a 540MByte download over a slow link for everyone 
> > > else.
> > 
> > Hmmm, clean-cg is 7.7G on my machine, and yes I tried 
> > git-prune-packed. What am I doing wrong?
> 
> "git-repack -a -d" gives me ~220 MB:
> 
>   $ du -s .git
>   222064  .git
> 
> anyone who can download a 43 MB tar.bz2 tarball for a kernel release 
> should be able to afford a _one time_ download size of 250 MB (the size 
> of the current kernel.org git repository). If not, burning a CD or DVD 
> and carrying it home ought to do the trick. Git is very 
> bandwidth-efficient after that point - lots of people behind narrow 
> pipes are using it - it's just the initial clone that takes time. And 
> given all the history and metadata that the git repository carries (full 
> changelogs, annotations, etc.) it's a no-brainer that kernel developers 
> should be using it.
> 
> (and you can shrink the 250 MB further down by using shallow clones, 
> etc.)
> 
> yes, some people complained when distros stopped doing floppy installs. 
> Some people complained when distros stopped doing CD installs. Yes, i've 
> myself done a 250+ MB download over a 56 kbit modem in the past, and 
> while it indeed took overnight to finish, it's very much doable. It's 
> not really qualitatively different from the 1.5 hours a kernel tar.bz2 
> took to download.

Probably that once in a while, we should set up a complete tree in a
tar.bz2 format on kernel.org. It would help a lot of people behind small
pipes. I have been encountering problems with git-clone when the link is
unstable. After the smallest error, it erases everything and you have to
retry from start, which is quite frustrating and expensive.

At least, downloading a tar.bz2 with FTP would be easier and a lot more
reliable. Also, people could download it from their workplace and bring
it home.

Willy