New repository creation page

[patrick-knight]

Thanks for trying out the new repository creation page.

The updated page makes it easier to create new repositories with a consistent modern experience.

The most significant change affects organizations and enterprises using custom repository properties and repository policies. Now, custom property inputs can respond to your organization's policies, letting you set or limit repository names and visibility right at creation. This helps maintain compliance from the start.

Opt out

To switch back to the classic creation page, disable the "New repository creation page" feature preview (learn more) or select "Switch back to classic experience" at the top of the creation page.

Feedback

Have a question? Have feedback? Let us know below!

[Perdolique]

I can't see an option to name the default branch as master. It creates main by default.

[patrick-knight]

That can be controlled today via repository settings. So if you are creating a repo on your account you'd set the default branch name here: https://github.com/settings/repositories

If it's a repos in an organization it would be managed via that organizations repo settings:
https://github.com/organizations/`org-name`/settings/repository-defaults

[Perdolique]

🤔 Thanks. Never heard about this input.

[ZianTT]

A bug report:

GitHub don't support "\n" in desc now, but the new creation page allow this. Finally it will cause an error with no hint.

maybe adding a limit is better? or add some hint more than "Repository creation failed"?

[patrick-knight]

Thanks for the note, do you have the full description you can share so we can try to reproduce this internally.

[ZianTT]

Thanks for the note, do you have the full description you can share so we can try to reproduce this internally.

just try to use following:

foo
bar

[patrick-knight]

Ohhhh! Sorry I read that as an actual \n in the description text not as a newline.

We'll take a look!

[patrick-knight]

Hey @ZianTT,
Wanted to follow-up and let you know we updated the text area interface to a single line to avoid newline inputs. Unfortunately supporting new lines on repository descriptions across the platform got quickly out of scope, but we'll keep it in mind for future improvements.

[merlinz01]

LGTM.

Feature suggestion: Add a "Create me" button on 404 pages under one's own account prefix, which takes you to the repository creation page and prefills the repository name based on the URL of the 404 page.

Then when I do this:

$ git remote add origin https://github.com/user/repo
$ git push -u origin main
remote: Repository not found.
fatal: repository 'https://github.com/user/repo/' not found

then I can just click the link and go straight to creating the repository.

[patrick-knight]

Thank you for sharing your thoughts on improving our 404 page. I appreciate the input. However, our 404 page serves multiple purposes beyond just indicating a repository doesn't exist, so we may not be able to implement your suggestion at this time.

If you're looking to quickly create new repositories from the command line, I highly recommend checking out the GitHub CLI. With a simple command gh repo create, you can spin up a new repo.

After your initial local commit you could even run something like this to create the repo and push up the initial commit:
repo_name=$(git remote get-url origin | sed -e 's/.*github.com[:\/]//' -e 's/\.git$//') && gh repo create "$repo_name" --public --source=. --push

[matiboux]

I've seen this a few days ago and it seems to coincide with this preview release, so I might as well point it out here:

On both the classic & preview experiences, the owner input no longer has a default selection when I open the repository creation page.

Previously, on the classic experience, my personal account would have been the default selection for the owner of the repository to create. This made the experience smoother and faster for the common operation of creating a personal repository.

Also, now has the side effect of hiding the visibility options until an owner is selected, showing the message "Please choose an owner to see the available visibility options." instead and causing UI elements to change position after an owner is selected. This causes confusion and can make the user inputs slower. This does not happen in the preview experience as visibility options are always shown in the configuration section.

This change of behavior feels like a step backwards, especially unexpected in the classic experience. 😢

Otherwise, the preview experience looks great and makes usual first steps to get started in a new repository faster, which is great! ❤️

[patrick-knight]

If you've recently been invited to GitHub Enterprise, your behavior may have changed. After being invited to an enterprise, the owner default selection becomes mandatory.

[matiboux]

Ah that is it. This is just a coincidence then!
An organization I've been in for some time was recently added in a GitHub Enterprise.
I was not aware of this behavior change, thank you.

[AyameU]

In GHEC with EMU, the preview flow includes "Public" as a visibility option. This happens when creating an organization-owned repository and a repository in my personal namespace. The classic experience does not allow the creation of public repositories (as expected).

Hoping this is a bug.

[patrick-knight]

Hey @AyameU,

Yeah that's a bug we're looking into. The repo couldn't ever get created but is something we'll get fixed to ensure that clear.

[patrick-knight]

@AyameU We just landed a fix for this, can give this a try again and see if you're seeing the same thing. Thanks!

[AyameU]

Hey @patrick-knight, the option is still showing on our end for org and personal repos.

[patrick-knight]

Hmmm...
Can you drop me an email patrick-knight [at] github.com so I can get some additional info from you

[dangervslash]

great job

[ghoway]

thanks

[jsoref]

Visibility is listed as "required", but at least for me, it has a value at the outset and therefore, I don't see why it should show a *:

It makes sense to use a * for Owner as I can try to not set it, and to have a * for Repository name as it starts without one. But Choose visibility shows Public for me, and I doubt that GitHub would ever show an empty value.

---

The label for the Owner field is Owner with descriptive text Choose an owner.
The label for the Visibility field is Choose visibility with descriptive text Choose who can see and commit to this repository

It feels like it should just be Visibility not Choose visibility.

[patrick-knight]

Thanks for the feedback @jsoref

The inclusion of an * for repository visibility is the result of partnering with our accessibility designers to ensure we are build forms that work for all.

As far as the descriptive text, we hd the opportunity to use choose an owner in the default state of the Owner field. The visibility options are responsive to the chosen Owner so we do want to relay that is an option that can be chosen, but does have a default value.

[jsoref]

That text is wrong then. You aren't using * to mean "this field is mandatory" you're using it to mean "we want you to think about the value of this field".

A mandatory field would be any field without a default value such that attempting to submit the form would fail. And clearly because there's a default value, the form could be submitted and thus it isn't functionally a "mandatory" field. It's a PLEASE THINK ABOUT THE VALUE FOR THIS FIELD.

I appreciate that you might work with accessibility designers. I worked on screen readers, with accessibility people, in the web accessibility standards bodies, and I have accessibility needs of my own (please take that in mind when reading my comments -- feel free to reach out to me outside of this discussion for more information/context).

If you want to call out that the visibility value may change as a result of users changing the owner, then you can (and should) do that (there are WAI-ARIA events for such things, but you should also make it visible to people who don't use screen readers).

[jsoref]

Fwiw, the behavior for Visibility is bizarre:

1. It starts out as Public with the Owner blank
2. If you select an Owner other than yourself, then the value changes to Private
3. If you then select yourself, then the value changes to Public
4. If you then select Private and swap to a different owner and back to yourself, it doesn't change back to Public

If Visibility was blank by default, then the * would make more sense.

It'd be even better if the value (Public/Private) was in italics until the user overrides it to hint that this is a default value. You could also use words Public (default for user) Private (default for organization). That would be accessible to all.

[jsoref]

I'm specifically annoyed by these edges because i'm constantly creating repositories, seeing Public, selecting an owner org, and then being surprised that the repository I created wasn't Public.

[jsoref]

Add README
READMEs can be used as longer descriptions. About READMEs

Normally descriptive text should relate to what's being done, not to dictionary definitions about things relating to what's being done. The Add README toggle adds one README, not a whole set of them. It doesn't add one in .github/ or .github/workflows or any directory other than / unless I'm not understanding what the flag does/how the flag works. This differs from Start with a template / Templates pre-configure your repository with files. which really can populate the repository with multiple files.

-READMEs can be used as longer descriptions. [About READMEs](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes)
+A README file can be used for longer descriptions. [About README](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes)

• (The fact that the linked doc title is wrong is immaterial to how you present the content. I filed a cross-linked ticket about it: Title implies there are multiple relevant README files, but the content relates to a single README.md file per repository github/docs#39707)

[dangervslash]

SO

[nathan-coleman]

I'm just here to say: I like the changes!

Sometimes the design changes I preview don't actually improve the user experience - they are just different. This change is really good though!

[jsoref]

The create gitignore feature only lets users choose a single item from a list (based on github/gitignore), but this doesn't make any sense.

It would be much nicer if it allowed users to check multiple items from the list.

If I have an angular app, I could easily want to use both:

• https://github.com/github/gitignore/blob/main/Angular.gitignore
• https://github.com/github/gitignore/blob/main/Node.gitignore

If I have a frontend and a backend, I probably want to use languages for both.
If I'm using a build system that's not very closely tied to my language(s), I probably want to use both the build system and the language(s).

[jsoref]

This is another preexisting quirk, but maybe you can fix it too...

The list of gitignore templates is sorted case-sensitively:

I can't think of a single good reason to do this from an end user perspective. I understand that people could try to write file names in non-Latin scripts, but I doubt that the gitignore repository would take a filename with non-Latin characters.

[jsoref]

One more (presumably preexisting quirk) about gitignore:
There's an entire directory called Global:

This directory contains globally useful gitignores, e.g. OS-specific and editor specific.

With one exception (Images.gitignore), it seems like it'd be useful if the create gitignore feature pulled in all of the "Globally useful gitignores". The images case should probably be addressed with a file named _Override_Images.gitignore with a note of the form:

# Projects often want to manage some small art files
# ... although larger files really shouldn't be managed in git repositories

# JPEG
!*.jpg
!*.jpeg

# Graphics Interchange Format
!*.gif

# Web P
!*.webp

# Portable Network Graphics
!*.png

# Scalable Vector Graphics
!*.svg
!*.svgz

# ICO
!*.ico