Torvalds Celebrates Git's 20th Anniversay. Is It More Famous Than Linux? (itsfoss.com) 90
Celebrating Git's 20th anniversary, GitHub hosted a Q&A with Linus Torvalds, writes Its FOSS News.
Among the other revelations: He says his college-age daughter sent a texting saying he's better known at her CS lab for Git than for Linux, "because they actually use Git for everything there." Which he describes as "ridiculous" because he maintained it for just four months before handing it off to Junio Hamano who's been heading up development for more than 19 years now. "When it did what I needed," Torvalds says, "I lost interest." Linus then goes on to share how Git was never a big thing for him, but a means to an end that prevented the Linux kernel from descending into chaos over the absence of a version control system. You see, before Git, Linux used BitKeeper for version control, but its proprietary licensing didn't sit too well with other Linux contributors, and Linus Torvalds had to look for alternatives. As it turned out, existing tools like CVS and Subversion were too slow for the job at hand, prompting him to build a new tool from scratch, with the coding part just taking 10 days for an early self-hostable version of Git.
In its initial days, there were some teething issues, where users would complain about Git to Linus, even finding it too difficult to use, but things got calmer as the tool developed further.
Torvalds thinks some early adopters had trouble because they were coming from a background that was more like CVS. "The Git mindset, I came at it from a file system person's standpoint, where I had this disdain and almost hatred of most source control management projects, so I was not at all interested in maintaining the status quo."
Among the other revelations: He says his college-age daughter sent a texting saying he's better known at her CS lab for Git than for Linux, "because they actually use Git for everything there." Which he describes as "ridiculous" because he maintained it for just four months before handing it off to Junio Hamano who's been heading up development for more than 19 years now. "When it did what I needed," Torvalds says, "I lost interest." Linus then goes on to share how Git was never a big thing for him, but a means to an end that prevented the Linux kernel from descending into chaos over the absence of a version control system. You see, before Git, Linux used BitKeeper for version control, but its proprietary licensing didn't sit too well with other Linux contributors, and Linus Torvalds had to look for alternatives. As it turned out, existing tools like CVS and Subversion were too slow for the job at hand, prompting him to build a new tool from scratch, with the coding part just taking 10 days for an early self-hostable version of Git.
In its initial days, there were some teething issues, where users would complain about Git to Linus, even finding it too difficult to use, but things got calmer as the tool developed further.
Torvalds thinks some early adopters had trouble because they were coming from a background that was more like CVS. "The Git mindset, I came at it from a file system person's standpoint, where I had this disdain and almost hatred of most source control management projects, so I was not at all interested in maintaining the status quo."
I see no reason to go beyond Git. (Score:5, Insightful)
If the origin site (GitHub, BitBucket, whatever) went down in flames overnight, it would only be an annoyance to our programming team, not requiring hoping and praying that the backups still work.
I keep Git repositories on my home NAS server for things as mundane as packing lists for various types of family trips. It just works, IMHO
Re: (Score:2)
Your personal version control evolution gave me flashbacks.
Re: I see no reason to go beyond Git. (Score:2)
Re: (Score:2)
I do have problems with Git: Rebase, squash merge etc. Because the real history is hard to visualise, people rewrite history, destroying the underlying information needed to do merges correctly, removing commits from history completely - commits you might want to keep because it might point to a version, where you code worked well. Why have the git community not added information to make a nice history overview instead of hacking the otherwise well functioning commit graph?
GitLab is a free, open-source GIT server that does what you desire [gitlab.com].
Re: I see no reason to go beyond Git. (Score:2)
Re: I see no reason to go beyond Git. (Score:1)
Re: (Score:2)
I don't know what problem you see. There were versions of gitk for visualizing history since a long time and the more polished version is gitg. Some IDE integrations can also draw a nice graph and some web applications for git do the same.
Re: (Score:2, Interesting)
As someone who started with Visual Sourcesafe, I find other source control systems awkward to use and lacking in features. It's been a long while since I've had a need for one but, at the time, they couldn't even maintain time/date information. You had no idea at all of what happened, when.
I'll assume that this has maybe/probably been fixed but, I wasn't about to migrate the company over to something that barely looked like an alpha release. VSS was crude and problematic but, it really just worked, aside fr
Re: (Score:1)
VSS never worked.
If you think, it did, you are in the lowest percentile of the population on this planet that ever used a version/source controll system.
Re: (Score:2)
What's the German word for being a gaslighting arsehole? Is there one? Or should we just call them all angel'o'spheres?
Re: (Score:2)
VSS was notoriously bad. Supposedly it was unpopular even inside Microsoft, who forced various groups to use it. Describing someone as "gaslighting" for saying it never worked is absurd. Even CVS was more usable.
The biggest issue was the locking paradigm where if someone checked out a file, nobody else was able to, because that was how it prevented conflicts. Nice and simple in theory, in practice utterly impossible to use in the real world. And that's just comparing it to CVS, which most considered inadequ
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
The time/date meta data is fine when it is correct with a properly written Makefile. The problem is most projects have never had a proper Makefile which is one of the reasons so many other build systems are out there. People don't seem to know how to build a proper Makefile. When Linus started with Linux, he was using systems that didn't do timestamps correctly and there were ugly hacks to keep things working. Even today some of those concepts have made their way into many other Linux based distros even
No Bugs/Issues if they went up in flames (Score:2)
sure the source would be there but not all the context like the bugs/issues if you read/watch the interview even Linus Torvalds acknowledges this is not good
Like readme create a standard folder and log them in that...
JJ
Re: No Bugs/Issues if they went up in flames (Score:3)
Re: No Bugs/Issues if they went up in flames (Score:1)
Re: (Score:1)
Git sucks (Score:2, Interesting)
Re:Git sucks (Score:5, Funny)
Re: (Score:2)
How many times has git screwed things up for you when all you wanted was to check in your code so it was backed up?
The answer is never. I have never done that. It's not hard.
It needs to separate backup functions (making them simple) and code merge/integration functions.
That's an interesting point.
Re:Git sucks (Score:5, Insightful)
How many times has git screwed things up for you when all you wanted was to check in your code so it was backed up? It needs to separate backup functions (making them simple) and code merge/integration functions.
It sounds like you mainly need to bone up on the concept of a branch.
Re: (Score:2)
Re:Git sucks (Score:5, Insightful)
Even CVS was better for the masses. How many times has git screwed things up for you when all you wanted was to check in your code so it was backed up?
If you want to use git as though it were CVS -- just to "back up" your files -- then it doesn't sound like you're getting too fancy. How could you screw things up?
And who are these "masses" you speak of? If they do any kind of semi-involved development work, and they still use CVS now, they would have torn out all of their hair by now. CVS manages files, not collections of them. Even Subversion would be better.
Re: (Score:3)
then it doesn't sound like you're getting too fancy. How could you screw things up?
The most common way is by rebasing changes that have already been pushed to the repository.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: Git sucks (Score:2)
*thatâ(TM)s* what you chose to whine about in his comment?
People with nothing to say attack minor points because they cannot address the issues
Re: (Score:2)
OK, something's wrong with you, and it's that you're using the name "master" instead of "main" or "HEAD." Fix that and Git will work fine.
You seem confused. "HEAD", and "master" and "main", are completely different concepts. First of all: "master" is the default branch name setting in git, despite the hysteria that suddenly caused many services to migrate to "main" (I still use "master" because why not?). Still, they are only different branch names, and some repos use "main" for their default branch, while others use "master". Second of all: "HEAD" simply points to where you have navigated to in the history and therefore is a different concep
Re: (Score:2)
: "master" is the default branch name setting in git, despite the hysteria that suddenly caused many services to migrate to "main" (I still use "master" because why not?).
You're obviously racist. Report to HR at once, account blocked.
Re: (Score:2)
I object so strongly to the premise that the branch "master" has been offensive to any black person in the history of ever that I set my defaults to "master-race" in protest
Re: (Score:2)
What is this "blocked to write and should have been in a new branch to be merged later"? Who imposed that rule on your repositories? It's not part of the default Git workflow.
If you join a project that applies particular rules and have a bad experience with those rules, don't blame the tool they use for your bad experience, especially if they did a bad job communicating those rules when you joined.
Re: Git sucks (Score:1)
Re: (Score:2)
"probably" is the key word there. That's a project-specific policy -- in particular that vs feature branches or pull requests from the maintainer of a given area -- that the project should have explained when he started working on it. It's not reasonable to say that Git sucks because of restrictions layered on top of it by third parties.
I would further argue that the main development branch should not be a production branch, and restricting updates for it to release managers is therefore a bad policy. It
unfortunately (Score:5, Insightful)
CVS development stopped when git started. CVS certainly is easier for small projects (e.g. three people working on their CS201 project) but it does not scale at all so there's no large-scale incentive to continue CVS development, and so there is no continued CVS development. You're expected to just bite the bullet and learn git. Or at least, learn enough git to not be dangerous.
This is really the overall problem with open-source software, there's either far too many projects solving the same problem or everyone gloms onto one or maybe two open source projects. You get too many when the community has yet to focus around any one project, so no one project has the resources to actually be good. You get one or two when the community has focused on one project and it becomes irrational to do anything other than build your own project on the existing project. "Two" usually happens when there's a licensing issue with the incumbent open source project and major players are incentivized to make something new.
There's a bunch of issues with this. One, it's a single point of failure in many different senses of the word (see, e.g., the xz hack by some intelligence agency -- and there are undoubtedly many others in the mainstream Linux projects which have not been detected). Two, it pretty much sucks all the air out of the room when it comes to innovating something better. At least with closed source projects, the fact that any competing project has the opportunity to make a lot of money is an argument to get investment to bootstrap the new project. (See, e.g., how so many closed source competitors of Adobe have sprung up as Adobe has gotten greedy and awful.) Three, because open source projects are largely funded and directed by a handful of mega-corporations, when they get together and decide to move onto something new (for reasons that benefit them and are not necessarily good for users at large) it's almost impossible to keep the old projects going.
Functionally, for most users of most open source projects, it's as if one monolithic company has decided to provide all software and you don't get any alternatives. We had more choice in the Unix days when the dozen or more major Unix vendors supplied their own stacks than today when your choices are Linux, Linux, Linux and maybe FreeBSD.
Re: (Score:2)
CVS certainly is easier for small projects (e.g. three people working on their CS201 project)
It's not. Download TortoiseGit and it's just as easy to use as CVS.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
We still use VSS to this day [...]
Dude, VSS is old. The latest release came out 19 years ago. It's one Windows update away from ceasing to function. You'd better not be depending on it. Migrate to something else, quickly.
[...must...resist...VSS...flame...war...]
Re: Git sucks (Score:2)
It's okay to be ignorant. But it's not fair to assume everyone else, too, just because of your own situation.
Re: (Score:2)
Limit yourself to the simple subset that e.g. svn uses and you avoid the problems. If you create a mess with git, then you created it. Without the advanced features you won't get a mess. svn commit is just "git commit -a", merging the SVN way is --ff-only and resolving the conflicts yourself. Branches do not need to be rebased, if you don't want to risk creating conflicting histories. You'll end up with something that is less powerful but may prevent some mess you can make with the powerful features.
Re: (Score:2)
Re: (Score:2)
Git is often a PITA but I'd take it over CVS in a heartbeat. There's a reason version control isn't the controversial subject today that it was back in 2000, when programmers swore at it rather than by it.
CVS isn't much better than just making regular back-ups. By contrast there's an entire ecosystem around Git enhancing discoverability and directly aiding the development process. It's one of the few times a modern development process has created obvious tangible upsides without any serious negatives - othe
It was a meteor moment (Score:5, Interesting)
Started with BitKeeper changing its license because someone in the community had tried to reverse engineer the protocol. Linus tried to defend BitKeeper, but the other devs were spending their days shouting at the BitKeeper guy while searching for something freer. Linux coding pretty much stopped.
Then one morning Linus posted git v0.1 and instead of searching for another system the linux devs spent the next week critiquing git. Then they started to add patches and within a couple of weeks the system was fit for casual use. Overnight git became the VCS that every dev used at home and dozens of other VCS' companies were out of business within the year.
Good times.
Re:It was a meteor moment (Score:5, Informative)
Started with BitKeeper changing its license because someone in the community had tried to reverse engineer the protocol. Linus tried to defend BitKeeper, but the other devs were spending their days shouting at the BitKeeper guy while searching for something freer. Linux coding pretty much stopped.
Then one morning Linus posted git v0.1 and instead of searching for another system the linux devs spent the next week critiquing git. Then they started to add patches and within a couple of weeks the system was fit for casual use. Overnight git became the VCS that every dev used at home and dozens of other VCS' companies were out of business within the year.
Good times.
I believe "Kernel SCM saga.." is the relevant LKML thread for the creation of git (although I can't find Linus announcing git 0.1 so perhaps there was also another thread) https://marc.info/?l=linux-ker... [marc.info]
Re: It was a meteor moment (Score:2)
The other devs were right to shout at the BK guy because he was acting unreasonably, dangerously paranoid and mentally unstable. Plus, the rug was already pulled under their feet, so they had nothing better to do. Linus knew he needed to something quickly to channel all that energy, so he sat down and created git.
Re: (Score:2)
It's a fine line trying to be all things to all people, an open source champion for the devs and contributors, and a closed source champion for the hardware manufacturers and device driver writers.
He is both, and personally I don't like it. We live in a wor
Re: (Score:2)
Also it's worth noting that:
1. The developer "reverse engineering" it had merely used telnet to connect to the TCP/IP port BK used and typed 'help'. That was literally it.
2. The dev involved was Andrew "Tridge" Tridgell, the developer of Samba, a critical Linux tool that wouldn't exist without reverse engineering. Suddenly people who had no problems with reverse engineering SMB felt the need to weigh in and attack Tridge for daring to type "HELP" at a prompt.
A horrible episode in Linux's history that, thank
Is Git More Famous Than Linux? (Score:4, Insightful)
Oblig. Monty Python (Score:4, Funny)
Stupid Git [youtube.com]...
Stallman thanked BitKeeper guy for being an ass (Score:5, Informative)
If Larry McVoy had not been such a hard ass about BitKeeper, many of us may still be using CVS, Subversion or shudder Visual Source Safe.
Stallman wrote an open letter, thanking him. https://www.gnu.org/philosophy... [gnu.org]
Re: Stallman thanked BitKeeper guy for being an as (Score:2)
Re: (Score:2)
Re: (Score:2)
All other tools are still present. svn? Some projects still use it. hg? Yes, still used. monotone, darcs, etc.? Yeah. Some of these have git bridges, which may make working together easier or cause chaos, but that's what projects using these software need to agree on.
Re: Stallman thanked BitKeeper guy for being an as (Score:1)
We always used version control... (Score:4, Interesting)
We have always used version control. For whatever reason, Git became the dominant platform. Nearly everyone in software development uses it, whether or not they have anything to do with Linux. That's why it's so famous.
A historical perspective might be interesting. It's really not clear why Git "won". Mercurial also offers distributed repositories, is OSS, and was first released at the right time. Why did Linus decide to "roll his own".
Re: (Score:2, Informative)
Re: (Score:3)
Re: (Score:2)
Re: (Score:1)
jj / jujutsu is the next generation. (Score:1)
Thank you pronoun "it" (Score:1)
You course corrected my reading comprehension
Still lacks file tracking, externals, and branches (Score:4, Interesting)
Git still can't track files, which is a major downside. I want to explicitly track when a file was copied or moved - git's detection heuristics often get it wrong.
Git still lacks svn externals. Submodules can't bind to HEAD of the external source, nor bind a single file. In development branches, I usually just want HEAD of whatever submodules there might be, and only maybe fix a specific version for a release.
Git still can't track branches. If you delete a branch, it's entirely gone from history. And there's no timestamp for when you created a branch. Branches are not real object in the repo.
In many ways, svn is still better. But git has won critical mass, so of course I use it. But not without grumbling.
Re: (Score:3)
If you decide that a branch is no longer worth pursuing, why would you need to delete it? Just leave it in the repository and move to a new branch just in case you ever want to go back to wonder "what the hell was I thinking when I created that old branch?"
"And there's no timestamp for when you created a branch."
I agree with this criticism. I haven't found a quick and easy way to locate the commit in the pare
Re: (Score:3)
Git doesn't track individual files because it tracks your project state. That's also why it doesn't let subprojects/remotes advance on their own: nobody has checked that combination at all. (The behavior you want has been responsible for many security holes when someone compromises a repo or project and others pull in a malicious version.)
Git keeps the objects for a deleting branch for a while by default, and you can recover the commit IDs from the reflog. It's just not true that it delete them immediate
Re:Still lacks file tracking, externals, and branc (Score:4, Informative)
I know how git is implemented, I just don't agree with all the choices. "git mv" is really just "mv; git add", so nothing is recorded about the move. And "git cp" is not a thing because git can't track files. This is a huge mess when re-arranging or splitting many files - git has no idea what actually happened, and just makes a guess. I want all such operations explicitly tracked.
As for branches, I want to be able to ask for "repo state at time X" and see all branches that existed at that time. Svn can do this, and you can even reuse branch names without ruining history.
Re: Still lacks file tracking, externals, and bran (Score:2)
People who dismiss other people's needs as stupid should probably take a long hard look in the stupidity mirror.
Re: (Score:2)
If you delete a branch it is gone. What did you expect? Don't delete it if you want to keep it.
You just keep it as it is. If you want to you can make up a name convention for branches you don't want to maintain anymore.
Re: Still lacks file tracking, externals, and bran (Score:2)
Why are branches any different?
Re: (Score:2)
Branches are different because they are not files. The semantics are intentionally different.
Oh, you accidentally committed secret data to your repository? I guess it's time to make a new repository because you can't remove access to anything you committed once. You should have checked before you committed, I guess.
Re: (Score:2)
You can "delete" with "push --force". But the unreferenced commits stay available for a while if you know their ID. But if people already know them, any way to delete history comes too late. The advantage of git is, that your commit is not automatically pushed. If you notice you've got your private key in a commit, you can still "reset --hard" to the previous commit and create a commit without the key and avoid pushing the commit that would leak the key.
Re: (Score:2)
A branch is a pointer to the latest commit in a history. Creating a new branch means creating a second pointer. Committing to the new branch means appending to a linked list (in that branch) and appending to a tree in the total git history. Merging two branches means continuing at a single branch, making the tree into a directed acyclic graph (DAG). Deleting a branch means deleting a pointer to the latest commit and losing the option to access it. You can still access the commit by ID or by tags (which are
Re: (Score:1)
Re: (Score:2)
If you look at what it is under the hood, you'll see that it is a rather simple concept. It may at first seem like overengineering, but in the end it is just a DAG recording changes.
Git is great (Score:2)
You've just got to commit to it.
Re: (Score:1)
Re: (Score:2)
But don't get too pushy.
More than just famous (Score:3)
More to the point, I'd say that Git is more infamous than Linux.
Look, it's a great tool... IF AND ONLY IF you have the same problem Linus had when he wrote it - that of a project the size of the Linux kernel with developers spread across the globe. It's a brilliant solution to that very specific problem. However, if you don't have that particular problem (and the vast majority of projects don't) it's an unwieldy Swiss-Army chainsaw that's only popular because that's what Linux uses (so it must be good!) and Github is free.
In fact, I'd go so far as to say that the mere existence of Github proves that people don't use git the way it was intended. Git's claim to fame is that it's a distributed system. Github, on the other hand, is a very central point. If you're going to use it as a centralized system you should probably be using a centralized VCS tool like svn. Quod erat demonstrandum.