The new code completion model announced yesterday is available today to all JetBrains users of GitHub Copilot.
To get started, ensure that you are on the latest stable release of the extension (v1.5.35 or above). Click the Copilot icon in the JetBrains IDE of your choice and select Edit model for Completion. This will open the GitHub Copilot settings, where you can switch between models.
A new code completion model, GPT-4o Copilot, can now be enabled by VS Code users.
This new model based on GPT-4o mini has additional training on over 275,000 high-quality public repositories in over 30 popular programming languages. As a result, you can expect this model to provide more accurate suggestions and to have better performance.
To get started, open the Copilot menu in the VS Code title bar, select Configure Code Completions... > Change Completions Model.... Alternatively, open the Command Palette and select GitHub Copilot: Change Completions Model....
If you are a Copilot Business or Enterprise user, you will first need your administrator to enable this model for your organization by opting in to Editor preview features in the Copilot policy settings on github.com.
If you are a Copilot Free user, using this model will count toward your 2,000 free monthly completions.
The model will also be available soon to Copilot users in all JetBrains IDEs.
Please share your feedback as you try out the new model. It will help us improve the experience for all Copilot users.
You can now view the content of a package with the updated code explorer directly on the npmjs.com portal. We have improved the reliability, performance and have now made this feature available for free. You no more need to download a package to view its content. With this feature, you can easily scrutinise packages to make sure it is safe for use in your application. The code explorer provides syntax highlighting for .js, .ts, .md, .json and other commonly used file types in npm packages. You can also view the content of any previous version of a package.
Start by exploring the npm package.
When opening a pull request from a comparison that only includes one commit, GitHub defaults the title and description to the subject line and body of that commit's message. Authors who write detailed git commit messages that adhere to the widely accepted convention of wrapping at 72 characters per line may have noticed that this can result in strange formatting because of how GitHub Flavored Markdown treats newlines.
We now take and automatically reformat the commit message when suggesting the pull request description, making it look just as good as the commit message it came from when viewed on github.com, GitHub Mobile, and other tools.
The repository file finder is a convenient way to jump to a specific file by typing part of its path. It can be accessed by pressing t or using the “Go to file” button.
The file finder hides files in directories like vendor/ and build/ by default. These exclusions can now by customized using linguist attributes in a .gitattributes file. For example:
vendor/** linguist-vendored=false
build/** linguist-generated=false
Learn more about the file finder
Learn more about .gitattributes
A warning is now displayed when a file's contents include bidirectional Unicode text. Such text can be interpreted or compiled differently than it appears in a user interface. For example, hidden, bidirectional Unicode characters can be used to swap segments of text in a file. This can cause code to appear one way and be interpreted or compiled another way.
This security issue is the topic of the Common Vulnerabilities and Exposures (CVE) publication: CVE-2021-42574. If your use of bidirectional Unicode characters is intentional and not malformed, you can ignore the warning.
To review a file for which this warning is displayed, open it in an editor that will display the hidden, bidirectional Unicode characters, like Visual Studio Code which highlights the characters by default. Then, verify that the characters are necessary and not disguising text that will be interpreted or compiled differently than it appears.
For more information, refer to Trojan Source: Invisible Source Code Vulnerabilities.
You can now set whether a repository allows forking when creating or updating it using either the REST or GraphQL API.
Previously, APIs for creating and updating repositories didn't consider the fields allow_forking (REST) or forkingAllowed (GraphQL). Now, this field can be set before invoking the API to configure whether a repository allows forking.
For reference, see documentation for the REST API and GraphQL API.
Previously, in the code browser, when you were searching for a branch by typing its name, a branch with the exact name of what you typed could appear at the bottom of the list of matching branches. This made it hard to recognize and sometimes requiring scrolling to the end of the list to select the branch.
Now, when a branch name exactly matches what you type in the search box, it appears at the top of the list of matching branches for faster recognition and selection.
Public repositories now have a public label next to their names like private and internal repositories do.
Previously, repositories had a label next to their name that indicated if they were private or internal, but there was no label if they were public. This led to people not recognizing that a repository was public and accidentally committing private code to it. Now, public repositories have a public label next to their name like private and internal repositories do.
Learn more about repository visibility.
To improve security and confidence in the authenticity of your contributions, you can flag commits and tags on GitHub.com that are attributed to you but not signed by you. With vigilant mode enabled (now available in beta), unsigned commits attributed to you are flagged with an Unverified badge. This can alert you and others to potential issues with authenticity.
The author and committer of a Git commit can easily be spoofed. For example, someone can push a commit that claims to be from you, but isn’t. Like showing a passport, committers can increase trust in their commits by signing them with a GPG or S/MIME key. And now, when you enable vigilant mode, commits will be flagged if they’re attributed to you but not signed by you. This raises attention if someone tries to spoof your identity as a committer or author. With vigilant mode enabled, all of your commits and tags are marked with one of three verification statuses: Verified, Partially verified, or Unverified.
Try it yourself! First, check out how to automatically sign your commits. Then, enable vigilant mode in your account settings:
Be sure to enable vigilant mode after you start signing your commits and tags. Once you enable it, any unsigned commits or tags that you push to GitHub.com will be marked "Unverified," including past commits.
Learn more about vigilant mode.
Pull request and review-related events are now included in the audit log at both the enterprise and organization levels. This helps administrators better monitor pull request activity and ensure security and compliance requirements are being met.
Events now included in the audit log:
Events can be viewed from the web UI, exported as CSV or JSON, or accessed via REST API. You can also search the audit log for specific pull request events. For example action:pull_request filters for events directly on a pull request, action:pull_request.merge shows just merge events, and action:pull_request_review shows review events.
Learn more about audit log and available pull request actions
The "Compare two commits" REST API, which returns a list of commits reachable from one commit (or branch) but not reachable from another, now supports pagination. It can also now return the results for comparisons over 250 commits.
To learn more, see the compare two commits API reference or the guide for using pagination.
To prevent unexpected changes from potentially slipping in after auto-merge is enabled on a pull request, auto-merge is now disabled automatically when new changes are pushed by a user without write access to the repository.
Note: users without write access can still update their pull requests to bring in changes from the base branch without having auto-merge disabled, but auto-merge will be disabled if the update results in merge conflicts that have to be resolved. This is to prevent merge-conflicts being deliberately used as a way to introduce code that hasn't been fully reviewed by the people with write access to the project.
Learn more about automatically merging pull requests when all merge requirements have been met.
Submodules defined with relative paths are now clickable in the web UI, making it easy to navigate to linked repositories. Previously, only submodules with absolute URLs were clickable.
Only relative paths following the format ../{repo} (a repository with the same owner) or ../{owner}/{repo} (a repository with a different owner) are supported.
To learn more about submodules, see Working with submodules on the GitHub blog.
