threads / discuss / 23394

Git and Linux tarball size evolution

Subject: Git and Linux tarball size evolution

## tl;dr

2 messages between Apr 9, 2010 and Apr 10, 2010.

replies: 1people: 2as markdown or json

Victor Grishchenko· Apr 9, 2010, 16:33 UTC · lore
http://bouillon.math.usu.ru/files/linux-tarball-evol.png
I plotted sizes of official linux kernel tarballs found at
ftp://ftp.kernel.org against their dates. (Yep, the methodology is
extremely dirty.)
Long story short: the normal dynamics of Linux development is
accelerated growth. Apparently, in the end of 2002, development hits
some limit, probably a scalability problem. It returns to the
accelerated mode in mid-2005, which event coincides with the
introduction of git (pointed by the arrow).
Speculation: indeed, the git lets development scale.

It is clear that git has changed the release pattern. But was it the reason why the development (and tarball size) returned to accelerated growth? Another possible interpretation is that 2.5->2.6 stage involved too much of reengineering, so "normal" incremental development slowed down for a while. Do git developers have any opinion on that? Thanks!

-- 
Victor
Alex Riesen· Apr 10, 2010, 11:31 UTC · re: Victor Grishchenko · lore

Re: Git and Linux tarball size evolution

On Fri, Apr 9, 2010 at 18:33, Victor Grishchenko <victor.grishchenko@gmail.com> wrote:

Show 5 quoted lines
> http://bouillon.math.usu.ru/files/linux-tarball-evol.png
>
> I plotted sizes of official linux kernel tarballs found at
> ftp://ftp.kernel.org against their dates. (Yep, the methodology is
> extremely dirty.)

Could you try using the sizes of *unpacked* tarballs? gzip/bzip2 will offset the real growth a bit (maybe even a big bit).

Show 5 quoted lines
> It is clear that git has changed the release pattern. But was it the
> reason why the development (and tarball size) returned to accelerated
> growth? Another possible interpretation is that 2.5->2.6 stage
> involved too much of reengineering, so "normal" incremental
> development slowed down for a while.
There were a lot of cleaning up in 2.5/2.6.
> Do git developers have any opinion on that?

The was Bitkeeper before Git, but also the development process has changed, with Linus becoming less of nexus of it. He does more merges than ever now, with a large part of integration and testing done by subsystem maintainers and people like Andrew Morton. Besides, you cannot ignore the developments outside of Linux world, which percipitate into kernel (things like new architectures).

← back to recent threads