linux-kernel - Re: Question about your git habits

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]

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/