Skip to content

Set via API whether a repository allows forking

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.

image

See more

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.

image

Learn more about repository visibility.

See more