[Update 20180604 @ 14:00 UTC: Acquisition confirmed. Microsoft is paying $7.5 billion in stock. Coverage at Microsoft, Security Week, The Register, and The Verge. Also, see the Microsoft blog post. --martyb]
Microsoft has reportedly acquired GitHub
Microsoft has reportedly acquired GitHub, and could announce the deal as early as Monday. Bloomberg reports that the software giant has agreed to acquire GitHub, and that the company chose Microsoft partly because of CEO Satya Nadella. Business Insider first reported that Microsoft had been in talks with GitHub recently.
Time to move off GitHub?
Previously: Microsoft Holds Acquisition Talks with Github
An AC also submitted Bloomberg's article.
(Score: 3, Informative) by nekomata on Monday June 04 2018, @02:00PM (22 children)
I have looked around for some alternatives, what I found was:
I also found FossilSCM (https://www.fossil-scm.org/ [fossil-scm.org]) but this seems to throw out the baby with the bathwater and replace git itself.
Any experiences/recommendations of those?
(Score: 3, Funny) by Anonymous Coward on Monday June 04 2018, @02:12PM (1 child)
Whats wrong with bitbucket?
(Score: 2) by Nerdfest on Monday June 04 2018, @07:04PM
What is wrong with BitBucket? Some news I wan't aware of?
(Score: 2) by VLM on Monday June 04 2018, @02:12PM (5 children)
If you want self hosted SCM, not so much world wide public membership in a project management, there's gitolite, I used that for years, professionally at one site.
Gitlab is where its at, has been where its at for some years now, also used that professionally at several sites and at home.
Now are you looking for strictly SCM or project management or wheres your balance between? I'm just saying if you want something weighted more toward project mismanangement there's always good old redmine.
Just remember that conceptually there's a difference between a SCM that happens to have some project mismanagement stuff cheaply bolted on, vs a complete project mismanagement suite that has a SCM bolted on almost as afterthought. I'm just saying that given a starting point of github, you can wiggle either direction quite a far way from the original balance.
The ultimate extreme of pure SCM is a host everyone can SSH into a shared project account (single sign on with kerberos, nfs home dirs, and ldap help a lot with this) and use SSH URLs in your git config, this actually works pretty well at implementing its extremely small list of features. Gitolite merely automates ACL stuff for that design.
The ultimate extreme of project mismanagement is one of those project management suites without any SCM integration at all, just a URL link on its project wiki to your git repo.
(Score: 2, Interesting) by nekomata on Monday June 04 2018, @02:40PM (4 children)
We started out on redmine (later w/ gitolite integration) but found it lacking for our "agile" needs. Basically managing a lot of very small tickets in redmine sucks (even with the agile plugin). However I very much like redmine for strategy/documentation/backlog tickets. Basically larger stuff that you won't "assign" to somebody, but first break apart. We still use redmine for that.
For development we moved to github, and also used the github project feature (for the small do-it implementation tickets). Now what we really use in github is the merge-req workflow, especially for commenting/reviewing. The kanban board. And the issues (a little). (And the repository itself obviously.) So not very much.
I played around with gitlab on a private server, but the amount of ressources it needs are quite massive. Also the whole system seems to be more complex than it needs to for us. That's why I was hoping to read some experiences, esp. from non-gitlab users ;)
(Score: 4, Interesting) by VLM on Monday June 04 2018, @03:03PM (3 children)
Eh ... I was motivated enough to check the vmware production image, ours has one CPU, 1.5 G ram (claims 250 megs active, probably doesn't need 1.5 G), 20 G storage, honestly not doing terribly much with not much resources. Its pretty wimpy compared to production servers (DB, etc) but pretty beefy compared to one of the DNS servers or one of the openldap servers. I would say its a solid medium size application.
My understanding of "gitlab on raspberry pi" is its usable, but not fast, although I've never seen it myself.
Most of its optional or OK to ignore. I remember spending maybe two hours getting jenkins and gitlab talking such that jenkins would autobuild and auto-test and auto-deploy to dev images when gitlab got a push, and jenkins would insert build results back graphically into the GUI on gitlab, and it was kinda complicated but all documented online and 100% possible to completely ignore if you don't want to do that kind of stuff. Kinda like MS Office products where the average user ignores 99% of the features but which 99% is ignored seems different for each user. But yeah gitlab is huge and you can spend a week messing with its weirder corners if you treat it like an adventure game RPG in exploration mode.
(Score: 1) by nekomata on Monday June 04 2018, @06:39PM (2 children)
>My understanding of "gitlab on raspberry pi" is its usable, but not fast, although I've never seen it myself.
I ran it on a 2G/2CPU VM for 2 users with maybe 3 small projects at the time, absolutely nothing special. After constant insane slowdowns I set up a cronjob to restart the whole thing every night just to work around the memory leakage. (don't remember the version, but it was 1 year ago, newest version at that time.)
I just killed the VM, never checked to see why it behaved like that (but it was a standard CentOS7 with the standard gitlab community install). My assumption at the time being "that's probably normal behaviour and nobody runs this thing on less than 16G of memory". Given your experiences, maybe I should give it another try.
(Score: 2) by VLM on Monday June 04 2018, @06:54PM
Never ran into anything like that in any location, with about 20 times the use stats you post but lower resources, musta been some kind of bug or config issue. Could be a unique feature thing where you had to enable XYZ for some local reason and XYZ is blowing it up, or some log file is getting spammed.
I once had a problem with a corporate vuln scanner that terrorized every open port 80, even internal use only ones, with roughly 5000 HTTP reqs per day one after another like a denial of service strike. That was annoying.
(Score: 2) by bobthecimmerian on Monday June 04 2018, @08:11PM
We see that at work too, we have a team of ~20 using Gitlab and we have to give the VM 10GB of RAM (with Gitlab as the only thing on it) and kill the process overnight in order for it not to hang. The source code repository is ~ 6GB and maybe 1.5 million LOC, but the speed problems are all in the web UI, clones, commits, and so forth are as fast as always.
(Score: 3, Informative) by JoeMerchant on Monday June 04 2018, @02:18PM (1 child)
Just to stir the pot, if you're leaving the cloud and hosting your own, trac-on-git is old school and quite reliable / trouble free.
One caution: back in 2009 I tried customizing the trac look, and it wasn't too hard to do, but I regretted it when we moved buildings and migrated the server off of an ancient desktop box onto a newer machine - other migrations without customization of the look and feel have been ridiculously easy by comparison.
🌻🌻 [google.com]
(Score: 2, Funny) by Anonymous Coward on Monday June 04 2018, @03:03PM
Please ensure the lawn is vacated by the time I get home from work.
(Score: 4, Funny) by Anonymous Coward on Monday June 04 2018, @02:33PM
For anybody looking for the code, here's the github links.
You're welcome.
(Score: 2) by JoeMerchant on Monday June 04 2018, @02:46PM
Maybe GitHub had these features, but if they did they didn't pop up "in my face" the way they just did in GitLab:
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Monday June 04 2018, @02:56PM
bitbucket can handle git just fine, so you may want to look into that as well.
(Score: 2) by c0lo on Monday June 04 2018, @02:58PM
Org hosted repo: https://osdn.net/docs/About_OSDN [osdn.net]
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 3, Insightful) by FatPhil on Monday June 04 2018, @03:07PM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Monday June 04 2018, @03:14PM (1 child)
So, do we laugh or cry here..?
(Score: 2) by c0lo on Monday June 04 2018, @06:43PM
Me thinks 'fallacy' is distorted beyond recognition in the product/service name.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 5, Interesting) by rigrig on Monday June 04 2018, @03:38PM (4 children)
I used Fossil for a while, as I liked the idea of one single (sqlite) file which includes everything related to the project (issues+wiki etc.).
It worked fine, but it's not git, so
* Integration with my IDE was nowhere near as smooth as for git
* You have to learn another tool, and the rest of the world uses git, so you keep switching between two almost-but-not-quite the same ways of doing things, which is annoying
* Even most technical people won't know how to use it, so instead of simply "git clone , poke around the code", they have to "learn about Fossil, install Fossil, learn how to use Fossil" before they can even download the code.
The git import/export both worked fine though, so the transition to and from Fossil is easy enough if you want to give it a try.
At work we use GitLab (as we want our data to stay inside our own servers) and we're quite happy with it.
Personally I'm not a fan of the open-core [wikipedia.org] business model though.
My hobby projects are now hosted in Gitea, because the system requirements are something my tiny server can actually handle.
It works great for my hobby projects, but being lighter also means it has a lot less features than GitLab.
No one remembers the singer.
(Score: 1) by nekomata on Monday June 04 2018, @06:47PM (3 children)
Well, after dismissing it out of hand earlier today I actually spent an hour playing around with it. And I have to say that the idea behind it seems to be pretty good. Also if history is part of your project, why shouldn't the wiki and issues and documents be? And the author of fossil is the main developer behind SQLite which I hold in quite high regard, just an amazing tool in general!
Here is a link [fossil-scm.org] explaining the main differences between fossil and git for anyone interested.
However I completely agree that there are a lot of downsides since, well, I first heard of fossil today for example ;) But it still might be worth trying out, esp. for a small closed-source team. Plus, while I think git is solid, it must have the worst fcking interface I have used in a terminal. The amount of pain that has caused me is probably sufficient for a case in Den Haag.
(Score: 2) by bobthecimmerian on Monday June 04 2018, @08:14PM (2 children)
:D our team is about 20 people, and the 10 or so software engineers are excellent. All but three of us learned git on this job, and we're fine. But having the QA team and sysadmins use git = pain. Lots and lots of pain. Some of the people on both teams climbed the same learning curve at the same speed as any of the engineers. Most are still climbing, and have a long way to go.
(Score: 0) by Anonymous Coward on Tuesday June 05 2018, @08:45AM (1 child)
Because maybe it's explained to them wrong??
Git is a multi-version file system. Every commit is a snapshot of how things were at a given time. And all the operations you do, like diffs, are simply run between the two versions of the source tree. Once you understand this, Git (conceptually) becomes easy to understand.
(Score: 2) by bobthecimmerian on Tuesday June 05 2018, @03:10PM
Even the terms you used in your "simple" definition assume a strong understanding of file systems, versioning, snapshots, and diffs.
I work with incredibly bright people who teach me things about all levels of computer science from networking to compiler design. But some of my other colleagues don't understand the distinction between a "commit" and a "push", they only have a partial grasp of "branches", they only have a partial branch of what, why, and how ".gitignore" works, and they absolutely don't understand how the different types of merges between branches changes the commit ordering in the history. Every few months someone does a bad branch merge and wreaks havoc for a while. (We have continuous integration that will tell us which set of commits introduced the chaos, but we don't have anything automated to revert merges.)
And on top of that, when things go wrong at your local command line, figuring out the correct solutions can be a nightmare. Conflicts, merge failures, line ending errors, etc...