Change the default for "Initialize repository with a README"

When I try to create a new blank project, the checkbox for “Initialize repository with a README” is always checked. Is it possible change the default behaviour of this checkbox to be unchecked?

Best Regards
BS

I contacted support and they were swift to give me this answer:

(answer shortened for brevity)

You could simply edit the HTML template and set the checkbox to unchecked there. I’ll have to mention that doing that counts as a modification of GitLab source, which technically will make your instance become unsupported. But that just means that in other Support tickets you’d be asked to revert back to the original version, and for such a microscopic change it really shouldn’t cause any issues. To do so, you’d need to edit the file /opt/gitlab/embedded/service/gitlab-rails/app/views/projects/_new_project_fields.html.haml on your GitLab server and replace true with false in line 66. There’s no need to restart GitLab afterwards.

I hope this helps anyone comming across this post in the future.

Would be nice for Gitlab to integrate this properly by a config entry in the gitlab.rb file. The problem I see with editing this file manually is that when you update Gitlab, I can envisage one of two scenarios:

1. The edited file will be replaced with a new one, and will need to be edited again to disable that option.
2. The edited file will not be replaced when gitlab-ce or gitlab-ee is upgraded, which potentially means any new project fields added in newer versions of Gitlab will not appear in your interface, or potentially cause other errors.

Yes. These are both valid concerns.

I would also like for GitLab to make this an option per server instance or group.

I opened an issue for it:

you can vote on it to attract interest which could help ensure it gets integrated quicker.

I am new to the whole ecosystem, so I have get used to where everything is and where feature requests should be posted. Thank you for opening an issue for this. I have voted on it.

I would go as far as questioning whether the default “checked” state is what most users want… I think we could have a small script check all repos created after the feature was introduce and see whether people tend to use it or not. Created a ticket for this as well: Make "Initialize repository with a README" unchecked by default (#383749) · Issues · GitLab.org / GitLab · GitLab

I personally use it, and want my repositories created with a README.md. That said I do understand that others do not want to. The issue was opened in the sense to allow choice, so that both types of people will be happy. I believe it’s unfair to take the option away and then force people like me to select it. Therefore, there needs to be an option that allows you to configure it how you want to make everyone happy.

Thanks for opening the issue, @iwalker! I stumbled on it (and now this thread) while handling a support case for someone also asking for this functionality.

I removed the workaround from the description for now, because it doesn’t seem to work in current versions anymore. The line number I gave in the response (coincidentally I was also handling the ticket where the workaround came from) was specific for the version of that support case, but even repeating the change on the correct line didn’t work for me anymore in my 15.8 test instance. (Look for initialize_with_readme in the file to get to the right spot – but *puts on Support hat* don’t modify it if. )

I’ll see if I can figure out a workaround for current versions as well and will update the issue in that case. To clarify, the first of your scenarios is what happens in practice: The file gets overwritten during upgrade, and you’d have to repeat the change.

@manuelgrabowski Thanks for the info hopefully there will be a more permanent option that could be used, eg: integrating somewhere in the Gitlab Admin (web) panel, or by editing /etc/gitlab/gitlab.rb - I feel that would be a more professional way of addressing, rather than hacking a file to remember where/how to edit and fix it again - although knowing if this is OK at least for a temporarily solution. I realise the more permanent method would require more work for it to be integrated though.