lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20071119044313.GC15227@1wt.eu>
Date:	Mon, 19 Nov 2007 05:43:13 +0100
From:	Willy Tarreau <w@....eu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Pavel Machek <pavel@....cz>, Mark Lord <liml@....ca>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>, protasnb@...il.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	alsa-devel@...a-project.org, linux-ide@...r.kernel.org,
	linux-pcmcia@...ts.infradead.org,
	linux-input@...ey.karlin.mff.cuni.cz,
	bugme-daemon@...zilla.kernel.org
Subject: Re: size of git repository (was Re: [BUG] New Kernel Bugs)

On Sun, Nov 18, 2007 at 03:56:11PM +0100, Ingo Molnar wrote:
> 
> * Pavel Machek <pavel@....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

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ