Results of first test with 198 patches. [LWN.net]

Results of first test with 198 patches.

Posted Apr 12, 2005 17:05 UTC (Tue) by StevenCole (guest, #3068)
Parent article: The guts of git

Linus seems happy with this first test. I just hope the disk usage doesn't become an issue down the road.

On Tue, 12 Apr 2005, Andrew Morton wrote:

>> 
>> This is the first live test of Linus's git-importing ability.  I'm about
>> to disappear for 1.5 weeks - hope we'll still have a kernel left when I
>> get back.

Yee-haa! 198 patches applied in less than 3 minutes. That's pretty exactly
the "one patch per second" I was aiming for (0.8 seconds per patch, so my
estimate from a few days ago of 0.75 was pretty much on the money).

	> du -sh .git 

	102M    .git

	> time dotest ~/andrews-first-patchbomb
	.. "Applying" messages scroll past ..

	real    2m39.840s
	user    1m40.594s
	sys     0m58.179s

	> time show-diff

	real    0m0.148s
	user    0m0.080s
	sys     0m0.068s

	> du -sh .git

	111M    .git

ie we added 9MB of stuff from a set of emails that totaled a 859kB mbox.

So say an expansion of about 10x over the pure emailed patches. Which is 
not out-of-line with my expectations, but considering that you _could_ 
have just compressed the patches and thrown the headers away and you'd 
have gotten a 190kB archive of just pure patches, it's not like this is 
hugely space-efficient.

I don't think I ever claimed it would be ;)

Anyway, I'm not going to release this tree, because quite frankly I want 
to double-check that everything went right, and I want to re-base the 
archive on some more history than starting _purely_ from scratch in 
2.6.12-rc2 (maybe from 2.6.11), but in general it looks good. Now, if I 
can get the stupid merging going on, it will actually be _useful_ ;)

			Linus

PS. Yes, the tree still builds after this exercise ;)

(Log in to post comments)

Results of first test with 198 patches.

Posted Apr 14, 2005 3:40 UTC (Thu) by StevenCole (guest, #3068) [Link]

I think "down the road" is exactly the time when we won't have to worry so much about disk usage. :)

With the continued improvement in disk storage capacity, I'm sure you're right. A related concern is network bandwidth. Not everyone has or can have a high-speed link.

Here is Linus and Andrew's take on the subject:

On Tue, 12 Apr 2005, Andrew Morton wrote:
>
> Linus Torvalds (torvalds at osdl.org) wrote:
> >
> > ie we added 9MB of stuff from a set of emails that totaled a 859kB mbox.
> 
> The total size of the commits list since Nov 2002 is 500MB, excluding those
> "merge" thingies.
> 
> So I assume that the git tree will grow at 2GB/year.

Yes, that's within my mental envelope. I was estimating a 3-5GB git
archive for the last three years of BK work.

The good news is that the way git works, you really can put the old
history in "storage" - throw it away (and just rely on the distribution
meaning that it's _somewhere_ out there on the net) or write it on a DVD
and forgetting about it. Most people really only care about the last few 
months.

Is 2GB a year a lot? I think it's peanuts, but hey, I can fill up my whole 
disk with kernel trees, and I wouldn't feel it's wasted space. Others may 
have slightly different priorities ("hey, I could fit 5000 songs in 
there!")

                Linus

Results of first test with 198 patches.

Posted Apr 14, 2005 19:07 UTC (Thu) by iabervon (subscriber, #722) [Link]

Hopefully, the system won't touch more history than is absolutely necessary, and it can be taught to only fetch from the home of the big disk the history it needs and doesn't have. That way, people will only download things that they actually need. Even if someone ends up with the complete history, 2GB/year is only 544 bps; so long as nobody has to wait for 5 GB to download at once, it's fine.

Results of first test with 198 patches.

Posted Apr 21, 2005 15:42 UTC (Thu) by huaz (guest, #10168) [Link]

I fully disagree.

It might be the right thing to do now because it's simpler to do, not because disk space is cheap. That is ALWAYS an excuse.

It's OK if git is just a linux kernel specific tool. If someone wants to make a general SCM on it, I wouldn't even want to try if I know it doesn't even support "diff".