If I have a repo somewhere (locally), right now I have to first go to GitLab and manually create a project.
When I create a new project locally, I want it to feel just as easy as instant Git branching to push my brand new project to GitLab, so that I don't need to leave my current context to go to GitLab to manually create project. I want to stay in the terminal and for using GitLab to feel as magic as using Git!
That can be much faster. My repo already has a name, GitLab has me as a user: we can simply allow the person to push to a specific git path to create a new project.
Proposal
I should be able to push a new project to my own personal namespace
I will receive feedback to setup my remote and view the project
remote:
remote: The private project JobV/awesome-new-website was created.
remote:
remote: To configure the remote, run:
remote: git remote add origin git@gitlab.com:JobV/awesome-new-website.git
remote:
remote: To view the project, visit:
remote: https://gitlab.com/JobV/awesome-new-website
remote:
```
If the project already exists, we process the push normally. If the user is trying to create a new project with a project name already in use it will be rejected because the projects will be diverged.
Ideas to reduce the scope of the first iteration:
only support the users own namespace: supporting groups and subgroups may not require much more development, but will require more testing.
Future ideas (out of scope)
Optionally we can allow you to set the visibility by using -o public-o internal:
-o, --push-option Transmit the given string to the server, which passes them to the pre-receive as well as the post-receive hook. The given string must not contain a NUL or LF character.
@Sytse that's an interesting idea, but if we do this in the UI, we can make it even more powerful (I think that's a different issue):
you create a new file in a project
when editing, you check Create a new project with this file instead
I don't know if that's good UX, because when would you actually create a new file in a project to then move it to a new project? Never, I'd say.
However, that does make us think about other options: A 'global' scratchpad where you can do this (this has been suggested by the product team before and there seems to be a need for a more higher level notepad / google docs competitor) or even a central / spawnable terminal to a clean host from which you can run commands.
So for someone that does all open source, how would this benefit them?
Either push straight from the command line, then go make the project public.
Make a repo online, and then push from the command line.
@connorshea did have a cool recommendation where there would be a link to project settings in the terminal after the push so that you can immediately go make it public if you choose to.
This could greatly benefit users only pushing repos they want to be public because then they get a link to the repo settings immediately. Reducing the amount of time it even takes to create a repo on the website.
Now for private repo users, this does absolutely get rid of a time consuming workflow. Great idea @JobV
A suggestion from @brodock to solve the private/public setting:
With recent git it’s possible to pass arguments to a push:
Transmit the given string to the server, which passes them to the pre-receive as well as the post-receive hook. The given string must not contain a NUL or LF character.```>So you can get creative.
@connorshea Not sure namespacing would be required because the push is initiated to a certain remote (GitLab in this case). That remote has full control over how the options should be defined, so if GitLab defines public as a valid option, it is fine I think.
I would like to suggest to keep the push option as simple as possible, because if the users needs to look up in the docs how to format the options, it would take away all the convenience we are trying to create here.
But I agree on you we should try to accomplish compatibility with other git hosts. Are we aware of any other git hosts that support push options?
If we are first, we can set trends rather than follow them...
FWIW, I don't like this. I see typos too often (mostly around case sensitivity) and creating projects based on typos seems bad to me… Is there a way I can say "please never auto create projects?" either at the deployment level or at least the user level? Could it default to false?
While this will be pretty cool, and saves having to use the web UI, I expect people are still going to have to set a remote before or after the git push. i.e. they're not going to type out the full URL to the repo every time they do a push. So why not encourage them to set the origin first?
Maybe the first push should respond with docs about creating a repo by pushing. That avoids accidentally creating a repo and provides the ability to create the repo as public. Just like running a CLI tool without the correct parameters.
$ git push origin masterGitLab: The project you were looking for could not be found.If you would like to create the project, specify the projectvisibility in the push options.Push options include "public", "internal", and "private".Example: git push origin master -o private$ git push origin master -o publicCounting objects: 2497, done.Delta compression using up to 4 threads.Compressing objects: 100% (1178/1178), done.Writing objects: 100% (2497/2497), 528.96 KiB | 0 bytes/s, done.Total 2497 (delta 1796), reused 1985 (delta 1284)remote: Resolving deltas: 100% (1796/1796), completed with 489 local objects.remote: remote: Your public project has been created!remote: remote: To view it online visit:remote: https://gitlab.com/deckar01/new-project/remote:
However, that does make us think about other options: A 'global' scratchpad where you can do this (this has been suggested by the product team before and there seems to be a need for a more higher level notepad / google docs competitor)
How about global Snippets having a Promote to Repo button
Project creation can fail (if the path is invalid, for example), so we need to print project validation errors
The user may not have added a remote yet, so it may be nice to also print the command to do that after successful project creation. We can look at the protocol of the push in question, and print either the SSH or HTTP URL dynamically
When we print Push options include "public", "internal", and "private"., we should make sure we take into account the allowed visibility options on the system and only print those
If a user tries to push into a namespace they don't have the permissions to see or create new projects in, like a private group or another user's personal namespace, we should not print instructions
If a user tries to push into their own personal namespace, we should only print instructions if they are allowed to create a new project (projects_limit)
If a user tries to push into a nonexistent group, we should only print instructions if they are allowed to create a new group
If a user tries to push into a nonexistent subgroup of an existing group, we should only print instructions if they have the required rights to create a subgroup inside that group
If a user tries to push into a nonexistent group, or a nonexistent subgroup of an existing group, and they have the rights to do so, we should create the group or subgroup with the same visibility as specified for the project
Per the specification of the Git pack protocol, as well as the source, push options are sent in the payload that goes from the client to git-receive-pack on the server. They are then made available to the pre-receive and post-receive hooks in GIT_PUSH_OPTION_<N> environment variables.
However, for a nonexistent project, we don't have a Git repo, or git-receive-pack, or hooks, or GIT_PUSH_OPTION_<N> environment variables. If we want to know what push options the user is sending along with their push, we need to convince the client to send us the git-receive-pack payload, and we need to parse it to get at the options, without actually using git-receive-hook, since we don't have a Git repository.
I see. If we want that, we would need to implement a proxy that can speak the git protocol to read and intercept the push options in the capability listing phase, not in the hooks
@DouweM I don't want to push the milestone out just because we don't know how we'd do it just yet.
I'll update the description which is quite specific about the solution, but let's reconsider the problem from the users perspective.
When I create a new project locally, I want to feel just as easy as instant branching to push my brand new project, so that I don't need to leave my current context of the terminal and using GitLab feels as magic as using Git!
Creating the project instantly is the ultimate magical experience where the user feels like they have superpowers. Are there other ways we can make creating a project more like push a new branch?
When I try to push a project that doesn't exist:
GitLab: The project you were looking for could not be found.fatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists.
The smallest change could be to offer them a URL to create the project like creating a merge request. This could probably be achieved in the next %"Next 2-3 months"
@brodock cool idea! Let's try to find a week in the next few releases to investigate and hack a prototype/experiment together.
The smallest change could be to offer them a URL to create the project like creating a merge request. This could probably be achieved in the next %"Next 2-3 months"
@DouweM I've updated the description to reflect out conversation this morning. The first iteration should always create private projects and completely avoid push options. Much of the discussion above is about the difficulty of this enhancement, so it should definitely be out of scope for now.
As discussed, only allowing users to create new projects in their own namespace reduces the number of validation and feedback situations we need to consider. This seems like a good simplification for a first iteration.
There are probably still more ways we can simplify the feature, like not showing a different remote URL based on the protocol they used, perhaps defaulting to SSH. Let's try to find a week in %10.6 to see how far we can get in 5 days building the smallest possible iteration.
There are probably still more ways we can simplify the feature, like not showing a different remote URL based on the protocol they used, perhaps defaulting to SSH.
@jramsay This is actually super simple to implement, and we already have this check in a few places, so let's keep it in scope.
In any case, first iteration looks reasonable to me!
@jramsay in terms of UX/UI what should we do for the feature? Should it just be announced in the blog post and docs and become kind of a hidden feature? Or should we announce it under the "New project" page?
As someone who maintains an enterprise gitlab installation I like the idea here, but please, include an option to disable this feature. Having hundreds of developers potentially creating new projects in the product structure at will is not a good idea.
@tnyblom you can restrict this by setting project limit to zero for all users who can't create projects. There is no difference between creating using push or the UI.
@brodock Will that not effect their ability to create personal projects?
Also creating a project via the command line will be more prone to typos in my mind.
That makes it an admin action to create forks too. I'd also like to see a way to disable this. I can imagine folks pushing a fork to their repo, but without the fork relations, MRs are useless.