Language Selection

English French German Italian Portuguese Spanish

Interview with Linus about Git

Filed under
Linux

Linus Torvalds didn't want to change software configuration management tools; however, business and open-source philosophy problems left the Linux founder with no choice but to abandon BitKeeper and create his own system: Git.

SCM programs are used to control the flow of updates and track program changes. In a project as large as Linux-more than 17,000 files-this can be very difficult and very slow.

Because most SCMs-such as CVS (Concurrent Versions System)-are too slow for him, Torvalds built his own.

He describes Git as "a stupid (but extremely fast) directory content manager. It doesn't do a whole lot, but what it does do is track directory contents efficiently."

t also can't be used with BitMover Inc.'s BitKeeper, the controversial and proprietary SCM that Torvalds had used to manage Linux kernel development.

"Git has a totally different model of representing the source tree," said Torvalds.

The name itself really doesn't have a meaning. Torvalds joked that it can be a "random three-letter combination that is pronounceable, and not actually used by any common Unix command. The fact that it is a mispronunciation of 'get' may or may not be relevant." Or, "'stupid. contemptible and despicable. simple.' Take your pick from the dictionary of slang." Or, "global information tracker: [if] you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room."

Git has already been used for its first run of Linux: the beta of Linux 2.6.12-rc3. But Torvalds admits that Git is still a work in progress.

"The roughness really comes from two things," said Torvalds. "It's a young project, and it just takes time for things to mature. That will go on for years, assuming none of the other open-source SCMs just eventually show themselves to be capable enough that we just end up deciding that Git was a good temporary bridge."

Also, Git does some things very differently from traditional source management, Torvalds said.

Full Story.

More in Tux Machines

Red Hat Announces General Availability of Red Hat Enterprise Linux 5.11

Red Hat, Inc. RHT, +0.07% the world's leading provider of open source solutions, today announced the availability of Red Hat Enterprise Linux 5.11, the final minor release of the mature Red Hat Enterprise Linux 5 Platform. Red Hat Enterprise Linux 5.11 reiterates Red Hat’s commitment to a 10-year product lifecycle for all major Red Hat Enterprise Linux releases and offers a a secure, stable, and reliable platform for critical enterprise applications. Read more

New Code Starts Lining Up For X.Org Server 1.17

X.Org Server 1.17 is planned for release at the start of 2015 and thus puts the closing of the merge window in the middle of October. While some xorg-server 1.17 code has already landed, more is on the way. X.Org Server 1.17 will continue with refining the in-server GLAMOR code that was merged with 1.16 for 2D acceleration in a generic manner over OpenGL. X.Org Server 1.17 is also looking to integrate the universal KMS mode-setting DDX driver. Keith Packard on Monday also shared several other code branches he's looking at as material for the 1.17 release. Read more

More Intel DRM Changes Queued For Linux 3.18, Including Old i830M Fixes

With the drm-next merge window for Linux 3.18 closing, Intel's open-source developers have submitted another round of changes for ultimately landing with the Linux 3.18 kernel. Intel has already sent in multiple pull requests of new DRM graphics driver code to push into drm-next for the Linux 3.18 merge window. Among the changes include various Cherryview improvements for the forthcoming low-power Atom SoC, and code clean-ups and continued Broadwell tweaks. Another Git pull request landed in drm-next over the night. Read more

Speeding up the Debian installer using eatmydata and dpkg-divert

The Debian installer could be a lot quicker. When we install more than 2000 packages in Skolelinux / Debian Edu using tasksel in the installer, unpacking the binary packages take forever. A part of the slow I/O issue was discussed in bug #613428 about too much file system sync-ing done by dpkg, which is the package responsible for unpacking the binary packages. Other parts (like code executed by postinst scripts) might also sync to disk during installation. All this sync-ing to disk do not really make sense to me. If the machine crash half-way through, I start over, I do not try to salvage the half installed system. So the failure sync-ing is supposed to protect against, hardware or system crash, is not really relevant while the installer is running. Read more