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."
"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, and hide the fact by shuffling the command-line interface around to be as obtuse as possible. Then later, after that company folds, we can write some wrappers to clean git up and nobody will be the wiser."
A lot of homosex amongst the unwashed, pasty greasy neckbeards?
Source forge is plagued with advertising and should be avoided at all costs. I, for one, am glad to live in a universe where git reigns free and supreme.
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.
Should sexist opensource developers have their projects censored or removed?
Recently an opensource game release story was removed due to the game developer's open sexism(0) and harrasment(1) of women in tech.
A story posted by the editor of the popular Phoronix linux news site about a release of an Open Source videogame was later manually removed(2). The reason cited was the game developer's unacceptable views on social issues such as gender equality (3).
The release story was titled "Xonotic-Forked ChaosEsqueAnthology Sees New Release - Phoronix" and can be accessed via the google cache(4).
With the recent inclusion of a code of conduct(5) for those wishing to contribute to the Linux Kernel some questions now need to be asked and answered about the inclusion of code from people who are known to engage in or promote socially unacceptable attitudes or harrasments of those whom the free-software movement would prefer to attract in their place:
* Are the social or political views of an author of free software relevant to that software's inherent quality?
* Should the beliefs of an opensource developer weigh when when evaluating whether a piece of opensource software is worthy of any publicity or public notice?
* Should men with unpopular or "forbidden" views be excised from the opensource movement and "not allowed" to contribute, in a manner similar to that which is done in employment?
* Has the free/opensource software movement changed in these respects since its founding? If so is this a positive change?
* Should there be gatekeepers to opensource that decide who may and who may not contribute. Should abusive developers be "blackballed" to maintain proper social order and controls?
and
* What are the consequences of not doing this
Citations:
(0) Past related incident: http://esr.ibiblio.org/?p=1310
(1) http://geekfeminism.wikia.com/...
(2) Removed story URL: http://www.phoronix.com/scan.p...
(3) http://www.phoronix.com/forums...
"Fortunately, the article has been removed now."
"Thanks everybody for speaking up."
(4) https://webcache.googleusercon...
(5) Linux "Code of Conflict"
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.
how bitkeeper fucked up and was swiftly relegated to irrelevance... you have to wonder how many of these are even still using bk......
There at Git? Or was it discrimination? Too fat? Too ugly? Trans-gender? Trans-half? Maybe two years or more back.
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.
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.
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.
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.
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.
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.