Since launching the new GitHub Desktop in 2017, we’ve focused on improving collaboration in the app, laying the foundation how you can work with Desktop today.
Today, we’re releasing GitHub Desktop 1.5, representing a culmination of the work we’ve been doing this past year. This release completes the merge collaboration cycle by providing a way to initiate a merge in the branch dropdown, guiding you through resolving merge conflicts, and informing you when a merge is complete. It also includes our first step toward improving onboarding onto GitHub Desktop with the option to clone and add new repositories in the repository dropdown.
With today’s GitHub Desktop release, you can merge with confidence knowing that even if conflicts occur, we’ll help you through it so you can keep shipping. Merge conflicts can be intimidating for new developers, especially those working in teams. In our usability tests, the audible “NOOOOO” when encountering a conflict became predictable.
In our previous release, we reduced some of that anxiety by informing you whether or not you would encounter merge conflicts before merging, but you still needed to actually resolve the conflicts on your own. With more than 10 percent of all merges in the app resulting in merge conflicts, we knew we could do better. And with GitHub Desktop 1.5, you’re no longer on your own. The app will now inform you which files have conflicts, route you to your preferred editor to resolve them, list the conflicts that you still need to address, and show you when everything is resolved and ready to merge.
As we’ve released features related to merging over the past several months, we’ve also had an opportunity to listen to lots of users. We care about your feedback, and this release incorporates several changes based on what we’ve learned from you. With GitHub Desktop 1.5, you can now initiate a merge from the branch dropdown, and you’ll receive feedback in the app to let you know when a merge is completed successfully.
We’ve also seen that the core function of adding a repository to Desktop has been difficult to find and use. We solved this by adding a simple way to create, add, or clone a repository right from the repository dropdown.
These changes are subtle, but together they represent our commitment to listen and learn from people using Desktop every day. We conduct user interviews and usability testing on a regular basis—if you’d like to participate and help make Desktop even more useful, please sign up.
Finally, we want to call out that this release is the first time we’ve shipped a feature iteration built almost entirely by community contributors outside of GitHub. The improved merge flow was a combined effort from @JQuinnie and @bruncun, and there were more than 30 merged pull requests from the community since our last release.
We continue to be blown away by the community that has grown around GitHub Desktop as an open source product. There were more community pull requests merged in September and October than in any previous months, and there’s no sign of slowing down. We’re grateful for the community’s participation in improving GitHub Desktop, and if you feel inspired to build something awesome together, we’d love to see you in our open source repository.
Have you ever been in the middle of writing a code comment and find yourself needing to switch context for a single minute? When you returned to the diff, did you find that your comment disappeared while you were in the middle of writing it?
In the latest release of GitHub for Visual Studio, we added the ability to save drafts of comments. As they are written, comment drafts are saved to a SQLite database and displayed when a user comes back to them later. Now, in-progress comments will never be lost again.
When reviewing a pull request, it’s common to write inline comments in the file diffs. Sometimes it’s necessary to switch back and forth between files (and other views) within Visual Studio. Now the diff can be closed and reopened and the in-progress comment is restored right where you left it.
After reviewing a pull request, it’s time to submit your review. From this view, you can navigate away and come back to the summary later so you can easily complete your review.
For creating a pull request, you can close the Create Pull Request form and return to it later—the title and description are filled out just as you left them. Even better, Visual Studio can be restarted and the content will be restored.
This is the latest feature we have added as we continue to build out our pull request workflow. Download the latest version of GitHub for Visual Studio and try it out.
Today we reached a major milestone: 100 million repositories now live on GitHub. Powering this number is an incredible community. Together, you’re 31 million developers from nearly every country and territory in the world, collaborating across 1.1 billion contributions.
Repositories are where you store code, but they represent much more: ideas, experiments, curiosity, and moments of inspiration. To celebrate, let’s take a look at a few trends and achievements, a core sample of what’s possible when we work together by the millions.
To put this milestone into perspective, we totaled only about 33,000 repositories in 2008. Today, we’re seeing an average of 1.6 repositories created every second. In fact, nearly one third of all repositories were created in the last year alone—all thanks to the developers who choose to host, build, and share their work on GitHub.
Over the last 10 years, it’s been a pleasure to watch impactful projects build and grow on GitHub. Rails moved to Git and GitHub while the platform was still in private beta, and Node.js launched on GitHub in 2009. Since then, we’ve also had the opportunity to host Swift, .NET, and Python. Supported by thousands of contributors, these projects are raising the bar for how developer tools evolve and engage with their communities.
Just this year, we’ve seen countless projects take off, started by individuals and larger teams alike. Projects like Definitely Typed, Godot, Kubernetes, PyTorch, and more climbed our lists of top and fastest growing projects.
Projects on this year’s lists have a theme: they make it easier to build software, whether through code editing, automation, containerization, or documentation.
This year, the open source repositories you’ve created span thousands of topics, but these are the ones you contributed to the most:
GitHub started with a small group of developers looking to solve a specific problem—now it’s home to a global open source community. And we’re seeing the proportion of open source contributors outside the U.S. grow every year.
As a continent, more repositories are coming from Asia than anywhere else in the world. More specifically, repository creation has picked up across Central Asia, the Middle East, and Africa. While there’s an increase in repositories from developed countries, we’re seeing the same trend in emerging countries as new tech communities grow and new technologies becoming more accessible.
Developers in Egypt, in particular, created twice as many public and private repositories this year. And in Nigeria, a growing developer community created 1.7x more open source repositories in 2018 than in 2017. To see why we think Nigeria has a tech community to watch, read our latest post on the region.
After 10 years and 100 million repositories, we’re only just getting started. Thanks to our users, we’re building something bigger than any single repository or project—a community that’s pushing software forward in tangible ways. So thank you for building with us now and in the years to come. We can’t wait to see what you build together in the next 100 million.
Interested in seeing more insights into the GitHub community? Check out this year’s State of the Octoverse report.
Today, we’re excited to announce that GitHub has joined 40 other software companies in supporting the GPL Cooperation Commitment. Our hope is that this change will improve fairness and certainty for users of key projects that the developer ecosystem relies on, including Git and the Linux kernel. More broadly, the GPL Cooperation Commitment provides an example of evolving software regulation to better align with social goals, which is urgently needed as developers and policymakers grapple with the opportunities and risks of the software revolution.
Regulations are put in place in order to achieve social goals—like reducing pollution or protecting consumers—but those goals aren’t automatically achieved. An “effective” regulation must direct behavior that will actually further intended goals and not cause too much unintended collateral damage.
But that’s not all: an effective regulation would also have an enforcement mechanism that encourages compliance rather than creates an opportunity to shake businesses down. Under effective regulation, the most severe penalties for non-compliance, like shutting down a line of business, would be reserved for repeat and intentional violators. Less serious failures to comply, or accidental non-compliance, may only result in warnings—if the violation is promptly corrected.
The GNU General Public License (GPL) is a tool for a private regulator (copyright holder) to achieve a social goal: under the license, anyone who receives a covered program has the freedom to run, modify, and share that program. (In contrast, a license like MIT does not regulate what freedoms downstream recipients must be offered. Whether to regulate in this manner or not is up to the developer of a program.)
However, if the developer does want to regulate, version 2 of the GPL (GPLv2) has one bug from the perspective of an effective regulator: non-compliance results in termination of the license, with no provision for reinstatement—making the license marginally more useful to copyright “trolls” who want to force companies to pay rather than come into compliance.
In contrast, version 3 of the GPL (GPLv3) fixed this bug by introducing a “cure provision” under which a violator can usually have their license reinstated—if the violation is promptly corrected. On choosealicense.com, we recommend GPLv3 when developers want to use a regulatory license.
Still, GPLv2 has served the Linux kernel, Git, and other developer communities well since 1991, many of which are unlikely to ever switch to GPLv3, as this would require agreement from all copyright holders, and not everyone agrees with all of GPLv3’s changes. But GPLv3’s cure provision is uncontroversial: could it be backported to GPLv2 licensed projects? In a sense yes, to the extent GPLv2 copyright holders agree.
The GPL Cooperation Commitment is a way for a copyright holder to agree to extend GPLv3’s cure provision to all GPLv2 (also LGPLv2 and LGPLv2.1, which have the same bug) licenses offered, giving violators a fair chance to come into compliance and have their licenses reinstated.
And importantly, the GPL Cooperation Commitment is an example of making regulation more effective in advancing a social good, like we discussed above. It also incorporates one of several principles (the others do not relate directly to license terms) for enforcing compliance with the GPL and other copyleft licenses as effective private regulation.
We’re happy to agree to the GPL Cooperation Commitment because it aligns with GitHub’s core values. Everything we build and support is grounded in empowering the people–and the community–behind the technology. We know GPLv2 will likely remain an important private software regulation for decades to come. It’s important to ensure that GPLv2 licensees have the ability to fairly correct license violations, and to support effective regulation that improves open source licensing for everyone. We also want to encourage both private and public policymakers to take similar care for effectiveness when considering regulation that will shape the future of software.
A new version of Git LFS, the open source Git extension for versioning large files, is now available. Git LFS v2.6.0 comes with a more robust authentication mechanism, new options to
git lfs checkout, a handful of bug fixes, new platforms, and more.
Git LFS can make two types of HTTP(s) requests: API requests (which allow the client to retrieve any metadata it might need), and storage requests (which allow the client to upload or download data to external storage).
Previously, Git LFS would determine how it should authenticate LFS API requests, then use the same method to authenticate transfer requests. However, API requests and transfer requests generally go to different places and aren’t guaranteed to require the same authentication method.
Git LFS now treats those requests as requiring different authentication and will determine the correct mode for each.
git lfs checkoutoptions
Git is designed to handle merge conflicts as best it can without the need for human intervention, but often it’s built-in merge facilities do not resolve conflicts correctly for large files. When that’s the case, it can be useful to compare the contents of both sides of the conflict by hand.
git lfs checkout now provides convenient options for doing just that: you can ask it to resolve “our” side of a merge, “their” side, or the merge base. Here’s an example:
$ git lfs checkout --ours --to=conflict.psd.ours -- conflict.psd $ git lfs checkout --theirs --to=conflict.psd.theirs -- conflict.psd $ git lfs checkout --base --to=conflict.psd.base -- conflict.psd $ ls -la -rw-r--r--@ 1 user group 16789 Oct 22 18:59 conflict.psd.base -rw-r--r--@ 1 user group 19810 Oct 22 18:59 conflict.psd.ours -rw-r--r--@ 1 user group 18303 Oct 22 18:59 conflict.psd.theirs
From here, you can open each side of the conflict and resolve the differences however you see fit.
You’ll see a handful of other new features and bug fixes in v2.6.0 like new release targets including arm64, enhanced support for more configuration options from Git, and more.
For instructions on configuring Git LFS, read the documentation.