Stories
Slash Boxes
Comments

SoylentNews is people

posted by chromas on Monday June 04 2018, @01:40PM   Printer-friendly
from the versionctlâ €-altâ €-del dept.

[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.


Original Submission #1Original Submission #2

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1) by nekomata on Monday June 04 2018, @06:47PM (3 children)

    by nekomata (5432) on Monday June 04 2018, @06:47PM (#688502)

    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)

    by bobthecimmerian (6834) on Monday June 04 2018, @08:14PM (#688540)

    :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)

      by Anonymous Coward on Tuesday June 05 2018, @08:45AM (#688777)

      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.

      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

        by bobthecimmerian (6834) on Tuesday June 05 2018, @03:10PM (#688880)

        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...