Offer the option to squash all the commits in a merge request to a single commit before merging. This keeps the history of the master branch clean (only a single commit). Rebasing on the command line is time consuming and error prone. Do not offer this option when there are already commits of this merge request branch in other branches.

It's currently only possible to create a fork under the namespace of the current user. If you like to create a fork of a repository within a group, you will need to fork to your user and than transfer it to the desired group/namespace. Forking into a group is interesting for companys having code ownership where projects do build theire stuff on common code repositorys.

It's currently only possible to create a fork under the namespace of the current user. If you like to create a fork of a repository within a group, you will need to fork to your user and than transfer it to the desired group/namespace. Forking into a group is interesting for companys having code ownership where projects do build theire stuff on common code repositorys.

In the UI it would be nice, perhaps optional, to go straight to folders that matter when you work with projects that have folders build like their package structure.

So when I reach "src/main/java" and I click "com", I go to "com/gitlab/ui" straight away, instead of having to click "gitlab" and "ui". With business logic of course to not do that when there are multiple files or folders.

UX needs to think about scenarios where you do want to go to a specific folder though.

I think it would be cool for us to be able to upload our own logo and branding to the user interface. I currently use Gitlab for my business and being able to "skin it" with at least my logo would be really cool.

- it is not possible to chose an arbitrary file name
- even it it were, if you forgot to tick the boxes when creating it would not be possible to fix things from the web UI without deleting the project.

This is part of the "No CLI series".

Currently, when you create a new project, it is not possible to access the file tab from which we can create new files, so it is not possible to create files for the empty repository

I propose we create a way for users to create a file with an arbitrary name for his new empty repository.

Suggested UI implementation (open to discussion): let the Files tab be visible even if repository is empty so that new files can be created from it.

What does Script do?
Well its like having gitlab_ubuntu_whatever.sh you can see in a repository in gitlab ( i forgot its name ) what it does is it installs every component of gitlab automatically without doing any sucky parts ( i guess whats left is the SQL, i haven't tried it because no available for CentOS). Why not make Script of Gitlab-CI more interesting. Like implementing how example given (.sh file).

For Example of it
* Giving timeout or delay per command ( not all command = 1 timeout/delay )
* If and else if Statements
* other stuff that can make building more complicated but easy

possible language for the script = maybe C or create your own :>

thats all

The title says the summary of this message.

What does Script do?
Well its like having gitlab_ubuntu_whatever.sh you can see in a repository in gitlab ( i forgot its name ) what it does is it installs every component of gitlab automatically without doing any sucky parts ( i guess whats left is the SQL, i haven't tried it because no available for CentOS). Why not make Script of Gitlab-CI more interesting. Like implementing how example given (.sh file).

For Example of it
* Giving timeout or delay per command ( not all command = 1 timeout/delay )
* If…

As an administrator for our development team, I end up being the owner of all the projects that are created - mostly because I'm the only one that creates them. It'd be nice to be able to change ownership to other people after creation so that repo admins don't have, like me, 30+ projects to their name, despite participating in 3 of them.

It would be nice if you could add descriptions to merge requests. This would be useful for providing brief descriptions of what the merge requests are about and why they are being submitted. Currently the only way to do this is with a comment on the merge request after it is submitted.