Slashdot Mirror
10 Years of Git: An Interview With Linus Torvalds
LibbyMC writes Git will celebrate its 10-year anniversary tomorrow. To celebrate this milestone, Linus shares the behind-the-scenes story of Git and tells us what he thinks of the project and its impact on software development. From the article: "Ten years ago this week, the Linux kernel community faced a daunting challenge: They could no longer use their revision control system BitKeeper and no other Software Configuration Management (SCMs) met their needs for a distributed system. Linus Torvalds, the creator of Linux, took the challenge into his own hands and disappeared over the weekend to emerge the following week with Git. Today Git is used for thousands of projects and has ushered in a new level of social coding among programmers."
A lot of homosex amongst the unwashed, pasty greasy neckbeards?
Man, you've been around for weeks now, nothing better to do?
I hear from so many people who love git, and also from so many people who see it as needlessly complicated to the point of getting in the way of getting things done. If that latter view didn't have any truth to it, this page wouldn't exist:
http://git-man-page-generator.lokaltog.net/
So, which is it? A useful tool, or simply a way for the the brightest technology people to feel smarter than everyone?
https://www.youtube.com/watch?v=4XpnKHJAok8
As a software developer who's been a git user for 7 years, I don't know how I could have written any serious code without git. Branching and merging is trivial. Cloning is trivial. The staging area makes choosing what to commit trivial. git rebase makes life much easier when it comes to reordering/editing/removing commits out of the history. git blame --- such a nice tool. Binary searching to find bugs is trivial. Every git tool is documented to within an inch of its life.
And the icing on the cake? Code cowboy hates git. Like sunlight or garlic to a vampire, Code cowboy abhors git. He can't hold the source code hostage to his every brain damaged whim. He can't hose anybody with a distributed version control system. It's no wonder why Code Cowboy is always yapping away at git -- he can't show off his genius if his code can be ignored.
git-r-done
That is: When you have a problem, fix it.
Let's not forget the other contender for replacing Bitkeeper: Mercurial. We will also be celebrating its 10th year anniversary next week during the Pycon sprints.
STFU, Mike. Nobody cares about you.
Who is this "Mike"?
Do you think sexist developers should be removed?
how bitkeeper fucked up and was swiftly relegated to irrelevance... you have to wonder how many of these are even still using bk......
I'll update our job posting immediately.
Every time I read "social" on an article summary about programming it's like a repelent for reading.
I think you missed the part where one developer reverese engineered how the protocol worked and the developer had enough of a shit fit that it became apparent that continuing to use their software was going to be problematic AND it was already the case that many people didn't want to use it for issues of licensing.
Even so, nobody is under any obligation to keep using a tool someone else makes, even if they like it. He put in the work. Nobody has some right to have others continue to use a service that they don't need and can handle for themselves.
"I opened my eyes, and everything went dark again"
Her name is Julie Ann Horvath, and she was at github not git.
She went to a company called &yet and then left a while after apparently to strike out on her own. AFAIKS she doesn't have any clie nts though.
Make of that what you will.
Only if the developer is a man. His code should not only be removed but he should be physically castrated along with 20 other men chosen at random as punishment for what he did.
Also, Git is and was an improvement over BitKeeper from a purely technical standpoint. Merging was easier, particularly with file renames. And Git was more performant. Here's a contemporaneous comparison from 2005, only one month after Git was publicly released:
http://www.selenic.com/pipermail/mercurial/2005-May/000334.html
BitKeeper sucked compared to both Git and Mercurial at the time. BitKeeper was definitely an improvement when it came out, but it was quickly surpassed by the open source alternatives.
Udacity has a free class on Git and GitHub. I recommend it. They spend a little too much time on writing a chart that diagrams the different parts of Git, but the class is well-structured and clear.
git is an essential - spent a lot of the later part of my working life trying to build something similar, but linus did it just right.
there is something about mr torvalds and the way he thinks that we cannot do without.
he finds methods that actually really work.
doing software without torvalds would be like riding fish without a bicycle.
It's worse than that. Linus would tell everyone not to worry and go on about how Bitkeeper was a great improvement and Larry would prove him wrong by throwing public tantrums and generally playing stupid licensing games. Ex banning IBM from using the free version since they had a competing SCM being built by another (far removed) department. Banning anyone who worked directly on a competing SCM from using Bitkeeper at all. And responding to said developer reverse engineering one of the export interfaces by discontinuing the free version of Bitkeeper.
The best part of it all was that Linus helped him design the thing in the first place.
So I was using this commercial software for a while, really clever stuff. But since I am moar cleverer I realized I could rewrite the entire thing as open source.
Ha! Good try, but Linus and Larry came up with the clever stuff together. Larry went too far trying to commercialize that cleverness (way too far).
I tried to give it time. I've used it daily for over a year. Have lost the days work several times with that crap-documented piece of shit.
A whole year with Linux, and I had it near mastered. A year with git, and it still sucks. Everything's a manual pain in the ass.
Linus: I ever meet you, I'm going to kiss you for the gift of Linux, then I'm gonna punch you in the mouth for all the time I've wasted on your shitty git thing.
he didn't "reverse engineer" anything, he connected to the bitkeeper port and typed "help" and bitkeeper helpfully told him what its commands were. so he used the commands.
a Git, for a Git and used by Gits
For instance, it is easy to add files to staging:
git add
Oops! A bunch of other things got added, because I'm a newbie and haven't yet tuned my
OK, have a guess at undoing it:
git unadd
wtf?...nope..
Frustrating searching to find that git reset is really unadd. Yeah, I could guess that! not.
And that's the crux of it. Sure you can add git aliases, but an xxx/unxxx pattern could have been built in right from the (ahem) git-go for any sensible command. Git commit/uncommit... merge/unmerge... etc etc.
And the great thing about git: Linus realised disk space was becoming to cheap to meter. Why bother crunching a delta on something when it was easier to just store compressed blobs. Thus the advantage of simple, fast and cheap (pick any three) branching.
Why should I have to understand internal data structures in order to use a piece of software?
Because you're not used to thinking about source code the way Git thinks about source code. Git is very much like a database from a usability standpoint, and you will probably get into bad trouble trying to use either without understanding both the problem that they are trying to solve and the implementation. If you do read about these things, you will understand that git's internals make sense, the decisions it makes are logical, and the user interface is (mostly) transparent and simple. Revisions are harder to manipulate than a Word document, though there are plenty of ways to manage them that are conceptually simpler. Git however was made to manage them efficiently. More specifically, it was designed to be efficient for Linus Torvald's workflow. That happens to be very effective for a large number of other software projects, and no worse than any other solution for many others. There are other workflows for which other RCS systems are better (particularly when working with binary files). If you don't need git's features, by all means use something else. However, your decision to use it or not should probably be informed by knowledge of what exactly it does and why: again, this is no different than choosing a database.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Actually, BitKeeper met all of the kernel developers needs and did it very well. A political fight broke out because the guys at BitKeeper wanted to actually be able to sell their work. Note that they guaranteed BitKeeper would always be free for Kernel developers. So as usual the Slashdot summary is wrong. They could in fact continue to use BitKeeper just fine.
Git was not a ripoff of BitKeeper.
It was primarily a ripoff of Monotone.
Which would be OK if Torvalds wasn't loudly claiming credit for every good idea in it.
This is a security failing that is hard to overlook for projects with far-flung participants. Any time data is downloaded it could be subjected to MITM attack.
Core git coders appear oblivious to the problem. Even so, how hard can it be to replace SHA1 with SHA256?
Loonix toreballs. Silly cult members.
Git is its own worst enemy
Sigh... Git. Ten years later, and it's still making people suffer with its unforgivably awful user interface. Seriously. I like the command line, and git is my primary version control system, but git's UI is the single most user-hostile example of human-computer interaction that I have had the misfortune to encounter in years. Maybe decades.
Git's command structure is a train wreck of inconsistencies, some of its most important terminology is worse than worthless, and its man pages and built-in help text are idiotically obtuse. I have been following its development closely enough to understand how it got this way. A lot of it has to do with placeholder terms that were never updated, synonyms that were never reconciled, features that were grafted onto existing commands and never properly organized, and its origin as a set of low-level components rather than a tool intended for humans. In other words, a pattern of evolution much like any other software, except for one thing: Even after years of being relatively stable, its mantainers still haven't addressed its glaring usability problems.
These aren't just minor warts that only affect a few people, either. There are countless articles, blog posts, and forum threads expressing frustration with git and detailing specific improvements that could transform it from a usability nightmare to an elegant piece of work. Sadly, the maintainers either ignore them or respond with some half-witted reason to resist change. Frankly, I am embarrassed to see my fellow software developers failing so miserably to recognize the importance of usability, and failing to fix it.
Newcomers shouldn't have to be encouraged to "take the time to learn git." It should be easy. A programmer familiar with version control systems should be able to pick up a new one in five minutes, and find the answer to most intermediate-to-advanced problems in maybe ten or fifteen. They should be able to walk away for a month or two, come back, and still remember how to use it. That doesn't generally happen with git. One has to invest quite a bit of time and patience to confidently use anything beyond its most basic operations without screwing something up, and stay in practice with it, or else end up having to learn most of it all over again.
The ridiculous thing is that it doesn't have to be this way. Mercurial is real-world proof of that.
I hate git for these reasons. It's a cantankerous bastard of a tool that will just as soon kneecap you as handle your data. I only use it because of github (which is brilliant, by the way.) If you want to see an example of how version control should be done, get to know mercurial. Its internal de
In git a "branch" is literally a mapping between a name and the commit ID of the commit at the head of the branch. If you've merged your commit into the main development trunk (submitting the bugfix) there is essentially zero overhead to keeping the branch around in your repository.
Some CI systems have a mechanism where you create what you think will be the fix, then push it up to a common area for testing, review, etc. Then you respin your fix based on feedback, send it back in. Rinse, wash, repeat until everyone is satisfied, then merge for real. In that sort of environment it can be handy to have one local branch per bug that you're working on.
So one branch per bug you're working on, one branch per feature you're working on, one branch per released version, etc. I just checked and one local git repo I'm working on is sitting at around 40 local branches currently.
I prefer the model where the "master" branch is the continuous trunk of development. When you want to release, you branch off for that release.
Functionally equivalent, but has the nice property that most stuff goes into "master" and only bugfixes/backports or special-case stuff goes onto the release branch.
I *never* do development on an upstream branch. So instead of the above I would always checkout the local "master" branch, do a "git pull", then checkout my development branch and rebase my work on top of the latest local "master" branch.
The nice thing about this is that the local "master" branch is always identical to some version of the upstream "master" branch, I never need to worry about it getting polluted with my development work.
The rule against using rebase really only applies if you are publishing your git repo (and specifically the branch in question) to other people.
The reason for the rule is that if you rebase your changes on top of the latest upstream, anyone pulling in your branch is then forced to rebase as well since you've essentially rewritten history. (Doing a rebase changes the hashes on all your local commits.) If you instead merge upstream work onto your local branch then your history is preserved and everyone downstream from you can also just do a merge.
However, for any development branch that you are not exporting to other people, "git rebase" is a very useful tool to keep your own development at the tip of your local development branch. When other people push changes you can pull them in and rebase your work on top of theirs.
That's not correct. McVoy pulled the free-licensed version of BitKeeper (which Linus and OSDL were using) because of Tridge's work on a compatible client, and refused to sell a BK license to OSDL because they had allegedly broken the terms of the free license. This despite the fact that Tridge was an OSDL contractor, not an employee, was working on an unrelated project, and never used the BK client itself to do his work.
Effectively, Linus and a bunch of other kernel devs would have had to quit OSDL (possibly forking Linux) to keep using BK.
There's a lot of up-voted git hate here. But I think this dislike isn't put into the right perspective. Yes, git is more complex than Subversion (for example). But, the expressive power granted by that complexity is worth far more to the developer than the cost to learn it. Here is a sample of things I do daily with git, that were either impractical or impossible using previous generation VCS'es like Subversion:
1. While working on one logical coding task, I'll often find an unrelated problem to fix. No problem, selectively commit the unrelated portion using git add -p then git commit.
2. I commit very often, usually many times per day. When I've added the feature or fixed the defect, tested it, and it is ready for use by others, I curate these 'piecemeal' commits -- using git rebase and friends -- into a logical sequence of changes that are then pushed to the shared repository. I get the best of both worlds -- very granular access to local changes in situ, then readable, complete and comprehensible commits pushed to the development team.
3. Larger structural code changes are hard to do, but git helps. Keep a long running topic branch 'close' to mainline development by frequently merging mainline into the topic branch. This avoids that huge merge commit hairball when integrating the long running topic branch back to mainline.
4. git rebase and friends are incredibly powerful if used correctly. Don't use them to change history but to create it. With these tools, re-organize a stream of frequent local commits into a small set of logical and comprehensive commits that achieve the end result. These curated commits are pushed as part of the unchanging project history.
5. Git makes it much easier to work on multiple tasks at the same time. Each logical task gets a local topic branch. Easy and fast switch between with git checkout.
6. Almost all of my development is remote. Git is a pleasure compared to Subversion in this case, because a full local clone means few commands have to actually contact the distant server.
7. Use a shared repository as a backup target for local branches. We use username/ prefixes for server branches that act as backups for developers' long-running topic branches, usually any that will last for more than a day. These are not project history and end up getting removed when the topic branches are ultimately merged into mainline.
8. When curating a topic branch and/or when merging it to mainline, merge/rebase conflicts will occasionally happen. I use vim with Tim Pope's fugitive plugin, which makes fast work of conflicts by combining vim's powerful diff mode with fugitive's git awareness. vimcasts.org has a couple of excellent video tutorials of using fugitive -- worth checking out for vim+git users.
I could perform all of the above tasks using Subversion, but it would take other tools and/or more time on my part. Git is tougher to get to know, but you only need to understand a portion of its interface to quickly access a significant amount of productivity enhancing capabilities.