11 ms·
The Linux kernel has surpassed one million git commits
- caffeinatedgoat 5y agoThere's really nothing significant about this, other than people like big round numbers.
- anothernewdude 5y agoWe really do.
- agons 5y agoThis can definitely be significant as part of a trend
- deleted 5y ago[deleted]
- macksd 5y agoThe millionth commit in isolation? Sure. The scale it takes to get into that order of magnitude? Quite an achievement.
- Ambolia 5y agoThere's nothing significant about anything, other than people liking it.
- tofof 5y agoSurpassed, not bypassed.
- DestruKaneda 5y agoBypassed? As in dropped 1 million commits?
- andrewclunn 5y agoTime to Squash it down to a few hundred thousand...
- bitcharmer 5y agoIt truly is the greatest open source project of all time. I just wish they moved away from email as the only way of contributing. It doesn't really scale well and definitely doesn't make contributing for newbies easier.
- LkpPo 5y ago30 years of contributions by email for the result that we know and you find that it is not a success? Shut up instead of talking nonsense.
- carstenhag 5y agoBring up arguments, don't tell someone to shut up because you don't share their opinion. Also, if the entire world would think like "30 years it worked fine", there would be absolutely no technology improvements the past 30 years.
- u801e 5y agoDoes Github work on a dial up connection? Does it work when you don't have an internet connection? Improvements in technology can do everything that old technology can do and more. Not supporting use cases that old technology did isn't an improvement.
- JasonFruit 5y agoYou know, that's not really true. For road transportation, a car is a great improvement on a horse — but it can't take you home when you're too drunk to guide it. Some things are an improvement in general, but still a compromise. A stronger argument would explain why the better technology is a bad compromise for this application.
- u801e 5y agoYou're working off an assumption that Github is a better technology. Many people who make this argument do not have extensive experience using both technologies. The arguments I've seen presented comes down to the fact that people cannot figure out how to set up email clients or how to send patch sets via email. It's not around an actual comparison of how these technologies operate or what compromises one has to make to use email versus Github or vice-versa.
- LeegleechN 5y agoClosing in on a nice, round 2^20!
- DecoPerson 5y agoI wonder if the Git project has tests for over 2^20 commits.
- globular-toast 5y agoGit's data model doesn't care how many commits there are. It doesn't care how many objects there are and commits are just one type of object. The git repo probably has tens to hundreds of millions of objects. The limiting factor is probably the filesystem, but I think most can handle it just fine.
- DecoPerson 5y agoThis really speaks to the reliability of Git. Are there any examples of projects with 1kk+ commits that use SVN, Mercurial, Perforce, or some other SCM?
- kibwen 5y agoI thought I read that Linux jettisons old history every few years for the sake of practicality, and that if you want the full history you have to look at special archive repos. Am I wrong? I wouldn't blame them; git is fast, but it's not that fast, and cloning becomes a bear after only a few hundred thousand commits (and I would be surprised if that's the only operation that scales poorly).
- CorrectHorseBat 5y agoNo they don't do that. Only happened once when moving to git: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- byroot 5y agoThat link is not responding for me, but here's a mirror: https://github.com/thorvalds/linux/commit/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://github.com/thorvalds/linux/commit/1da177e4c3f41524e8...
- jedimastert 5y ago>1kk That's going in the ol' geek toolbox
- the8472 5y agojust use the other SI prefixes. 1M. https://en.wikipedia.org/wiki/Metric_prefix#List_of_SI_prefixes https://en.wikipedia.org/wiki/Metric_prefix#List_of_SI_prefi...
- totorovirus 5y agoIn next version of Sid Meier's Civilization there should be Linux Kernel in technology tree.
- 1_player 5y agoWouldn't that make it available to only one civilization? Should be a shared Wonder all civilizations would benefit from.
- Waterluvian 5y agoThe tech tree is researchable by everyone.
- pletnes 5y agoExactly - linux was built only once in real life.
- eru 5y agoTechnologies are usually available for everyone to research.
- nicklecompte 5y agoI think they mean that when a civ researches (or “builds”) Linux every player in the game should have access to it (but the civ who spent the resources building Linux gets something extra). If Linux was on the tech tree, only the civilizations who researched Linux could use it. That’s not very FOSS! Every civilization who had computers should be able to get Linux once it’s out.
- throw0101a 5y ago> I think they mean that when a civ researches (or “builds”) Linux every player in the game should have access to it (but the civ who spent the resources building Linux gets something extra). Actually that would be an interesting mechanic: to move forward in the tech tree you have to research something, but by researching it you give it all the players. Do you stall your own progress, or take the hit to move forward and float all ships higher by raising the technological tide? How do the devs program the AI countries to make choice(s) in single-player, and what would a human player do? Who blinks first?
- tannhaeuser 5y agoNow, the question is when systemd surpasses Linux in terms of commits/LOCs ;)
- NieDzejkob 5y agoPerhaps I'm blind, but I can't actually see the number of commits on this page.
- dorianmariefr 5y agovisible on the github repo https://github.com/torvalds/linux https://github.com/torvalds/linux
- sfgweilr4f 5y agoWhich files get the most commits? Which sections of each files get more than usual commits? eg which functions? Who wrote this particular function first? who subsequently? How many of those include expletives? Curious minds need to know. If I want to answer these earth shattering questions, could I just grab the entire git repo and go from there? is it that simple? is it text exportable without too much "other" scary?
- mobilemidget 5y agoAfter you calculated all that and let us know :) https://gource.io https://gource.io To create visuals of the gitrepo history/commits.
- sfgweilr4f 5y agowhat a fascinating tool.
- bogota 5y agoYou could. But I would recommend downloading it to a RAM disk to make generating that a bit faster. The which function sees the most use would likely take a bit of work to figure out.
- 19h 5y agoI’d find a list of files that have the least changes more interesting (excluding text files et al.). And then check if the lack of activity is related to the stability of the code, lack of use or its complexity.
- sega_sai 5y agoHere is the top 20 files by the number of commits 12846 MAINTAINERS 4167 drivers/gpu/drm/i915/intel_display.c 3330 drivers/gpu/drm/i915/i915_drv.h 2360 drivers/gpu/drm/i915/i915_gem.c 2328 arch/arm/Kconfig 2118 arch/x86/kvm/x86.c 2079 sound/pci/hda/patch_realtek.c 2019 Makefile 2001 fs/btrfs/inode.c 1927 include/linux/sched.h 1903 net/core/dev.c 1888 drivers/gpu/drm/i915/i915_reg.h 1824 arch/arm/boot/dts/Makefile 1801 drivers/gpu/drm/i915/intel_pm.c 1781 include/linux/fs.h 1763 arch/x86/Kconfig 1737 mm/page_alloc.c 1643 kernel/sched.c 1628 fs/btrfs/extent-tree.c It's quite interesting how present intel gpus are in the list, which probably tells something about the code on them...
- kibwen 5y agoHow do other open source projects compare? I'll admit, I would have figured that Linux had passed one million commits some time ago, and I feel like web browsers might give Linux a run for its money here.
- aexl 5y agoThe "mozilla-unified" repository seems to be at 646.5k commits and the "chromium" repository at 999.5k commits.
- gigatexal 5y agoThe world is so much better off with Linux and Linus and his merry band of hackers. They do an amazing job keeping up with the sheer amount of work that goes into the kernel from everyday needs like you and me to patch sets from companies. But what I am most proud of is git. It’s not perfect but since learning its warts it’s the Swiss Army knife of awesome just like GNU find is for me on the terminal.
- muterad_murilax 5y agoHonestly expected it to be way more.
- cryptica 5y agoPart of me wonders why nobody tries to make software like we make buildings... After some time, it's all done and nothing else needs to be added. People will be quick to point out that "the hardware keeps changing so the software has to adapt". This is true, but why not design the software in such a way that different drivers can easily be substituted (so the drivers can change but the interface doesn't)? I did this with my open source project. I haven't made any code changes for over a year and it still works perfectly and still relevant. I don't understand why there is such a fetish in this industry for never finishing any project. I find the whole attitude very frustrating.
- DC-3 5y agoYou know buildings also require maintenance, right?
- sophacles 5y agoAnd they regularly get overhauls and additions.
- cryptica 5y agoHardly any compared to software. We're talking about 1 change every 20 years versus 1 to 100s of changes per day. That's a huge magnitude of difference. But that's not even important to my argument. To suggest that software maintenance and building maintenance are anything alike is ignoring the entire context of the two activities. With buildings, builders have very little control over the wear and tear caused by the environment. In software, developers collectively have total control over the software and hardware environment which determines whether or not software breaks. Most of the wear and tear in software is a direct result of people compulsively changing stuff in other software (or hardware) up the stack - It's all 100% avoidable. If the software never changed materially (aside from bug fixes), it would not break. Simple as that. And most of the software changes are simply taking us round in circles. New generations of developers undoing the work of the previous generation, then later reversing direction again, surely we've all seen it happening at most of the software companies we've worked at...
- bpodgursky 5y agoLot of people view 1mm as a huge number of commits. Which maybe it is... if your team has a habit of big PRs + rebasing. On the other hand, if your team is used to making quick iterative commits, throwing them in a PR, never rebasing, and pulling in merge commits all over the place, uh, I can attest that you can get to a million commits pretty fast.
- peterkelly 5y agoThe next time you hear someone make an argument against remote work, remind them of what has been achieved in the last 30 years by the Linux kernel developers working across so many different countries and time zones.
- readams 5y agoJust imagine how much easier it would have been if they were all in the same place.
- GoOnThenDoTell 5y agoThe core devs meet up all the time at conferences
- wheels 5y agoSo, I like working remotely, but there are many fallacies in your statement: Distributed open source projects are obviously an example of survivorship bias: the people who thrive in them are those that work well in a distributed environment. Contributors are also usually self-motived (again, by survivorship) in a way that one wouldn't expect of rank-and-file office workers. Also, the existence of a thing doesn't show that its genesis was an optimal path to its current state. Additionally, large open source projects are not necessarily good at converging upon a particular goal. They do well when the goals of many individuals or small groups aggregate well. It would be very difficult to convince all of the kernel team to, e.g. optimize for mobile performance for the next two years. Nobody contests that large things can be done by distributed teams. Usually there's contention that a particular set of employees, that work on a particular set of projects / goals can be transitioned to working that way.
- u801e 5y ago> Distributed open source projects are obviously an example of survivorship bias: the people who thrive in them are those that work well in a distributed environment. Contributors are also usually self-motived (again, by survivorship) in a way that one wouldn't expect of rank-and-file office workers. Couldn't the same argument be made for those who thrive in an office environment and need to be around other people to work effectively as well as those who are not self-motivated? I guess it really depends on what the majority prefers from a worker/contributor point of view.