LWN: Comments on "The guts of git"

Linus has guts

nix — Thu, 17 Mar 2011 14:58:33 +0000

With six years' perspective, this comment is quite amusing. Most of the core of git is unchanged from this earliest sketch: one thing has been renamed (cache -> index), but the only major new concept is packfiles, which have zero impact on anything but disk space.

I think we can say that git is by now more than a 'downgraded monotone sketch' :)

Howto checkin git hook

nix — Mon, 17 Aug 2009 20:22:54 +0000

You can't push hooks, just as with everyting else under .git/: it would be
dangerous, if you think about it, because hooks are executable code!

You have to use some other mechanism (ssh, whatever) to install it at the
server end.

Howto checkin git hook

dajoe13 — Mon, 17 Aug 2009 17:13:55 +0000

I have not been able to find out how to commit and push a hook to my git server archive for everyone's benefit. The githooks man page does not descrive this and I have not turned up any fruitful google searches on the topic.

I am trying to add a post-checkout hook. I also noticed that the post-checkout sample does not exist when I init a new archive. I am running git version 1.6.0.2.

Regards,
Joe

Results of first test with 198 patches.

huaz — Thu, 21 Apr 2005 15:42:25 +0000

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".

Great name, but ...

vonbrand — Wed, 20 Apr 2005 18:26:54 +0000

Hummm... if <joke> ... </joke> doesn't work, maybe <joke> ... </joke> does ;-)

The guts of git

proski — Fri, 15 Apr 2005 21:45:23 +0000

You cannot just multiply the number of revisions by the number of files unless you change all files in every revision. The files that don't change between revisions are not stored as separate copies (because their SHA1 checksum is the same). In fact, if you revert to original file contents, the repository would be reusing the old files.

Great name, but ...

tzafrir — Fri, 15 Apr 2005 14:20:08 +0000

s/r/z/ and you get the answer:

http://zsync.moria.org.uk/

The original idea and initial implementation was by the same Tridge but he had to stop develop it.

The guts of git

njhurst — Fri, 15 Apr 2005 07:49:17 +0000

Have you considered for loops?

The guts of git

joey — Thu, 14 Apr 2005 21:02:18 +0000

hmm, I've done some calculations before on checking out all revisions of all data I keep in my subversion repositories. IIRC, checking out all versions of all files in my ~3 gb of repositories would need closer to 1 terabyte of data than 100 gb. Not very practical for laptop use. :-)

The guts of git

proski — Thu, 14 Apr 2005 19:49:46 +0000

I guess you need to define _GNU_SOURCE for the st_* fields and include unistd.h for missing declarations. Userspace programming with all those compatibility issues is so much harder than the kernel, it's it? i:-)

Results of first test with 198 patches.

iabervon — Thu, 14 Apr 2005 19:07:59 +0000

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.

Linus has guts

dlang — Thu, 14 Apr 2005 18:44:30 +0000

the other projects have had three years to develop a better SCM solution.

as Linux pointed out in the announcement that he was going to look at other options for SCM they aren't useable yet for something the size of the kernel yet.

we'll see if git ends up beng a dead-end system or the base for a better system in the future, but it has a very different focus then the other SCM options.

every one of the other options is starting with what the UI is, what commands the scm will implement. git is starting from the other direction and building the low-level pices (and building them to be fast) and then layering the UI on top of that.

this seems like a much better approach to take, and the other SCM systems can take advantage of these primitives as well (assuming they are willing to live with a linux-only limitation or the slowdown from other systems that don't have some of the underlying infrastructure that git is counting on in the OS for it's speed)

Linus has guts

kevinbsmith — Thu, 14 Apr 2005 14:38:11 +0000

At first, I thought Linus was wasting his time (and that of others) on git. It is still possible that he is, but if he really has found a super-simple alternative to the complexity of other distributed SCM systems, then he has really achieved something remarkable. Sometimes it takes an outsider to see what the experts overlook.

If (almost) anyone else had pitched this idea to him, I doubt Linus would have paid any attention. If (almost) anyone else had come up with git, they would not have immediately attracted a community of developers to help build it. Linus also has the advantage of targeting a single workflow process within a single project. That's far easier than creating a generic tool.

If someone can wrap a true, minimal but functional generic SCM around this thing, I will try it. I like minimalist simplicity. We should know within a few weeks whether the fundamental ideas are a good foundation, or have dead-end limitations. At the moment, I'm betting it will work.

One other thing: I wish the authors of the various free distributed SCM's could gather to critique git's future possibilities. Assuming they could set aside their own biases, they are in the best position to point out limitations and guide the design.

The guts of git

lyda — Thu, 14 Apr 2005 12:19:01 +0000

i can't get git 0.04 to compile on a redhat 7.3 box.

update-cache.c: In function `index_fd':
update-cache.c:26: warning: implicit declaration of function `close'
update-cache.c: In function `fill_stat_cache_info':
update-cache.c:68: structure has no member named `st_ctim'
update-cache.c:70: structure has no member named `st_mtim'
update-cache.c: In function `match_data':
update-cache.c:116: warning: implicit declaration of function `read'
update-cache.c: In function `main':
update-cache.c:282: warning: implicit declaration of function `unlink'
make: *** [update-cache.o] Error 1

Linus has guts

filipjoelsson — Thu, 14 Apr 2005 11:34:00 +0000

Hmm, if it takes Linus two hours to merge a patch-bomb, I think he has put less time into developing this new foundation for an SCM - than he would have been spending waiting for one of the existing SCMs merging his patches over the next month or two.

Others are spending time inventing fancy algos, theories, and such, but fail on the real-world test. Why should Linus not scratch this desperate itch then? Why should he come to an existing project, and overturn it with his rather extreme demands? Does he have the time to wait for one of them to "grow up"? I think not. Remember that he is working full time, whereas many contributors to smaller projects are programming in their spare time. Thus, waiting on the spare-time programmers would be rather frustrating.

So, it's not a question about Linus being a rock star. It's a question of efficiency.

Linus has guts

Tobu — Thu, 14 Apr 2005 09:58:09 +0000

What a sucker, this Linus guy.

I mean: for years, he's been ignoring the free SCM, on the grounds that they "didn't scale" for such a large project as the kernel. When he finally is bitten, he still scorns the alternatives, and comes up with a downgraded monotone sketch.
Being something of a rockstar, he'll get away with it, and will get enough developper support because people must still be able to talk to his tree; but in terms of development time, he's just throwing others' work out of the window.

Results of first test with 198 patches.

StevenCole — Thu, 14 Apr 2005 03:40:46 +0000

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.

mattdm — Wed, 13 Apr 2005 22:37:55 +0000

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

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

Great name, but ...

wjhenney — Wed, 13 Apr 2005 17:13:39 +0000

Hmm, I thought the winking emoticon was sufficient. Next time I'll try to
be more explicit. Unfortunately, <joke> ... </joke> is rejected by the
comment editor if you post as HTML.

Previous git

edomaur — Wed, 13 Apr 2005 14:50:15 +0000

and even Gentoo and Gentoo :)

Great name, but ...

dpash — Wed, 13 Apr 2005 14:44:33 +0000

rsync is GPL. If Tridge stops distributing it, you can still use older versions.

The guts of git

ekj — Wed, 13 Apr 2005 09:27:41 +0000

But in the context of source-code it's obviosuy true. Not nessecarily so for all other contexts.

Source-code is *very* small and *very* compressible in relation to how much work it takes to produce it. If you invest a million dollars in developing some software over a year. *ALL* revisions of *ALL* files can still be stored, completely uncompressed for a storage-cost in the pennies-range.

There ain't anyone seriously working on Kernel-development that has a problem storing 10 or 100GB in order to do so efficiently. And hardisks are less than a dollar/GB.

git Mailing List

PaulDickson — Wed, 13 Apr 2005 07:21:32 +0000

I totally missed the announcement about the git mailing list. I only saw
a single refersnce to it. Here's a link:

http://vger.kernel.org/vger-lists.html#git

The guts of git

bronson — Wed, 13 Apr 2005 04:36:40 +0000

I love Linus's attitude. "Disk space? Heck, it's not a problem now. If it becomes a problem, I suppose we'll fix it then." (my paraphrase) I've worked on a number of projects, failed of course, that needed this sort of pragmatism.

Great name, but ...

iabervon — Tue, 12 Apr 2005 22:51:52 +0000

Linus writes a replacement, obviously. :)

Great name, but ...

wjhenney — Tue, 12 Apr 2005 21:19:23 +0000

The current head is obtained from the remote repository (using rsync) and compared with the local head. If the two are the same, no changes have been made and the job is done.

The remote object database is downloaded, again with rsync. This operation will add any new objects to the database.

... so what happens when Tridge pulls the free version of rsync? ;)

Previous git

khim — Tue, 12 Apr 2005 19:47:00 +0000

What, indeed ?

-rw-r--r--    1 0        0            8751 Jun 06  1996 git-4.3.10-4.3.11.diff.gz
-rw-r--r--    1 0        0           55745 Aug 30  1996 git-4.3.11-4.3.12.diff.gz
-rw-r--r--    1 0        0           76156 Nov 12  1996 git-4.3.12-4.3.13.diff.gz
-rw-r--r--    1 0        0           39461 Dec 05  1996 git-4.3.13-4.3.14.diff.gz
-rw-r--r--    1 0        0           35846 Dec 24  1996 git-4.3.14-4.3.15.diff.gz
-rw-r--r--    1 0        0           12872 Jan 28  1997 git-4.3.15-4.3.16.diff.gz
-rw-r--r--    1 0        0          336211 Jan 28  1997 git-4.3.16.tar.gz
-rw-r--r--    1 0        0          402888 Mar 14  1998 git-4.3.17.tar.gz
-rw-r--r--    1 0        0            5629 Jun 29  1999 git-4.3.18-4.3.19.diff.gz
-rw-r--r--    1 0        0          406138 Jun 01  1999 git-4.3.18.tar.gz
-rw-r--r--    1 0        0           21475 Mar 13  2000 git-4.3.19-4.3.20.diff.gz
-rw-r--r--    1 0        0          406914 Jun 29  1999 git-4.3.19.tar.gz
-rw-r--r--    1 0        0          426648 Mar 13  2000 git-4.3.20.tar.gz

I think we can safely presume it's abandoned. And we already have ACE and ACE, BALSA and BALSA, FUSE and FUSE, etc... So... What is the problem ?

monotone 0.18 with some speed improvements came on the 11th

ber — Tue, 12 Apr 2005 19:26:13 +0000

On the April 11, monotone 0.18 was released with
some speed improvements. Linus is in the credits for the speed improvements, too.

http://www.venge.net/monotone/

Previous git

bkw1a — Tue, 12 Apr 2005 17:48:29 +0000

But what about this:

$ man git
...
NAME
git - GNU Interactive Tools

SYNTAX
git [options] [path1] [path2]
gitps [options]
gitview [options] filename
...
DESCRIPTION
git is a file system browser with some shell facilities
which was designed to make your work much easier and much
efficient.

An amazing set of "eyes"

hppnq — Tue, 12 Apr 2005 17:08:33 +0000

The road Linus has more or less laid out seems to be exactly the right thing to do too. I don't think it is a coincidence that Linus kicked off this project himself: it almost ensures that many talented people will want to be involved (by coding or reviewing) -- and that there is a sound base on which those people can build great SCM software.

Open Source in action, it is still amazing.

Results of first test with 198 patches.

StevenCole — Tue, 12 Apr 2005 17:05:07 +0000

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 ;)

An amazing set of "eyes"

b7j0c — Tue, 12 Apr 2005 16:42:53 +0000

Apparently all bugs are shallow with enough eyes looking at them - well this tool has an exceptional pool of eyes looking at it - the kernel devs. I would not be surprised if this tool becomes good, quickly.