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] [thread-next>] [day] [month] [year] [list]
Message-ID: <998d0e4a0802221823h3ba53097gf64fcc2ea826302b@mail.gmail.com>
Date:	Sat, 23 Feb 2008 03:23:49 +0100
From:	"J.C. Pizarro" <jcpiza@...il.com>
To:	"Al Viro" <viro@...iv.linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Question about your git habits

On 2008/2/23, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Fri, Feb 22, 2008 at 05:51:04PM -0800, Junio C Hamano wrote:
>  > Al Viro <viro@...IV.linux.org.uk> writes:
>  >
>  > > On Sat, Feb 23, 2008 at 02:37:00AM +0100, Jan Engelhardt wrote:
>  > >
>  > >> >do you tend to clone the entire repository repeatedly into a series
>  > >> >of separate working directories
>  > >>
>  > >> Too time consuming on consumer drives with projects the size of Linux.
>  > >
>  > > git clone -l -s
>  > >
>  > > is not particulary slow...
>  >
>  > How big is a checkout of a single revision of kernel these days,
>  > compared to a well-packed history since v2.6.12-rc2?
>  >
>  > The cost of writing out the work tree files isn't ignorable and
>  > probably more than writing out the repository data (which -s
>  > saves for you).
>
>
> Depends...  I'm using ext2 for that and noatime everywhere, so that might
>  change the picture, but IME it's fast enough...  As for the size, it gets
>  to ~320Mb on disk, which is comparable to the pack size (~240-odd Mb).

Yesterday, i had git cloned git://foo.com/bar.git   ( 777 MiB )
Today, i've git cloned git://foo.com/bar.git   ( 779 MiB )

Both repos are different binaries , and i used 777 MiB + 779 MiB = 1556 MiB
of bandwidth in two days. It's much!

Why don't we implement "binary delta between old git repo and recent git repo"
with "SHA1 built git repo verifier"?

Suppose the size cost of this binary delta is e.g. around 52 MiB instead of
2 MiB due to numerous mismatching of binary parts, then the bandwidth
in two days will be 777 MiB + 52 MiB = 829 MiB instead of 1556 MiB.

Unfortunately, this "binary delta of repos" is not implemented yet :|
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ