Choose name when Forking

I have a project that serves as a template and I use this project as the "base" for several other projects. Unfortunately, there is no ability choose the resulting fork name, before the act. Also, you cannot fork the same project twice into the same target namespace.

Proposal

I propose a change such that:

• the initial name of a fork can be changed before the fork is performed.
• if the chosen name exists in the target namespace
  • then disallow forking (existing behaviour)

current workaround is:

• fork to personal namespace
• rename project and change path
• transfer project to target namespace

Does this use case actually suggest that we'd like the ability to copy projects, rather than fork? We have the same scenario, many times, where the new project does not need to, perhaps even should not, be linked back to the original.

In fact, for some use case we don't even need the entire repository, but just the tip of master, or a specific tag or branch.

Yeah, I think its fair to say its more a copy than fork.

Thinking about it, my derived projects are never going to push back to the upstream. I may, however, need to pull down from the upstream (common fixes to the base); but that is done locally per derived repo.

Added feature proposal label

Added ~307502 ~113220 labels

@regisF This is another highly requested feature, auto renaming on forking or manual renaming on forking. Can this be assigned and tackled?

Do people make forks so often that we need to enhance the current flow?

This would actually eliminate a lot of headaches for my workflow. We use private forks of a master repository for students to do their work in and I've found that the fork/rename/transfer method can be a little non-deterministic.

I've had cases where the API/importer simply can't keep up, since there is no way to determine when the fork/import finishes. I've ended up renaming/transferring a repo before the import was finished and students end up with blank repositories and cleanup is a mess. I've had to add a lot of sleeps into my codebase and just hope that it finished before I try to transfer the fork. It goes so much slower now I was considering looking into communicating directly with the work queue.

mentioned in issue #17358 (closed)

/cc @mydigitalself

added ~480950 forking labels

added shortlist label

This makes also sense when forking one of the GitLab pages examples (https://gitlab.com/pages). In that case it would also be helpful if you could remove the forking relationship upon creation.

Maybe something like this? (cc @awhildy)

Large screen

Small screen

Of course some more explanatory text would be great.

Thanks @winniehell! I like it!! Basically, we auto fill in the suggested name and path, but you can easily change it if you want and/or uncheck keep the forking relationship, right?

Would this be a good Accepting Merge Requests issue?

we auto fill in the suggested name and path, but you can easily change it if you want and/or uncheck keep the forking relationship, right?

@awhildy Yes, that was my intention.

I had some thoughts on how to improve this a little bit further, but if you are already happy with this, I would make that a second step.

Would this be a good Accepting Merge Requests issue?

This probably involves backend changes, so at least some guidance for a contributor would help. But otherwise I think it is small enough, yes.

I'll add the label and see if anyone is interested.

added ~123454 label

/cc @tiagonbotelho

This would be amazing to be merged along with !5760 (closed) MR that I started but did not complete since it has not been yet scheduled. WDYT \cc @JobV @DouweM

Sounds good to me @tiagonbotelho

Could we then schedule for what release we should do it? @JobV

That's up to @mydigitalself, @tiagonbotelho.

Would be good to have a clear idea about the amount of work required.

mentioned in issue gitlab-com/peopleops#83 (closed)

I had some thoughts on this issue after going through the code:

• Having a different name shouldn't be any trouble, just pass it as a parameter.
• Having a new path will require changes.
• lib/gitlab_projects.rb in gitlab-shell will need to be modified to handle the change of path between forks.
• In order to have the new path in available in gitlab-shell, the path would have to be passed through everything ($GITLAB_SHELL/lib/gitlab_projects.rb, lib/gitlab/shell.rb, app/workers/repository_fork_worker.rb and app/models/project.rb). This could have a knock on effect on anything that uses the modified routines.
• I am not exactly sure the best way to deal with the fork relationship. The code currently requires the relationship to do the initial fork, should the UnlinkForkService just be called after the fork?
• The "new fork" page will have to be redone. Currently the picture of the user/group is just a link with the post method and with a URL query in it, this would need to be changed to a form so the new name/path can be submitted. I had an idea to turn each of the pictures in to a button than can submit the form and also send the namespace id when clicked. This won't work because somewhere in the javascript code, the default behaviour of this kind of button is overridden and the value contained in the button is discarded.
• Will any changes be made to the API?
• All sorts of new tests will have to be written.

Edit: I have done a basic version at jameshclrk/gitlab-ce@e3425600 and jameshclrk/gitlab-shell@1cb2e8f4

mentioned in issue #15263 (closed)

mentioned in issue #17634 (closed)

As requested in issue #17634 (closed) setting the visibility in the fork dialog would make things much easier. Currently, it is very difficult to fork a public project into a private group; you would have to create a temporary group, adjust visibility there and move project into the final namespace then.

Hence, when changing the fork related API this should be considered too.

https://gitlab.zendesk.com/agent/tickets/73824

added SP3 ~65372 labels

added SP2 and removed SP3 labels

Had a peek at the code written by @jameshclrk and was thinking perhaps it is heading the right direction for this.

1. As he mentioned, does not look like the gitlab-shell support fork_project with a custom project name; which can be useful for this implementation of custom project name.

2. Instead of using the UnlinkForkService. I think if we want to support copy, we may need to do something with https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/models/project.rb#L518 The import will only work, if the project is a forked, and it is only a fork if it has a link relationship with the base project. A clone project should not have that. Maybe an opportunity to refactor that, and explicitly call either import/fork/copy?

mentioned in issue #32420 (closed)

mentioned in issue #23393 (closed)

mentioned in issue #36268

marked this issue as related to #36268

This had Accepting Merge Requests (https://gitlab.com/gitlab-org/gitlab-ce/issues/13208#note_23308999), not sure what happened. I'm adding it again.

added Accepting Merge Requests label

After considering my mockup above again, I think it makes sense to make the page more similar to the new project page:

@sarrahvesselov What do you think? Should this go through some more UX work before it's being worked on?

added UX label

What do you think? Should this go through some more UX work before it's being worked on?

I like it @winh, I think this is a great first iteration. I don't think there is a need to do more UX at this stage. I will update the description with these mocks and label it 'UX Ready'.

changed the description

added UX ready and removed UX labels

mentioned in issue #14567 (moved)

moved to gitlab#4254

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue