When forking a project into a namespace, the fork name cannot be changed. If for example user wants to create a second, private fork of an already forked project, this is not possible via the GUI. API allows for this customization, but the same workflow cannot be achieved via the GUI.
Proposal
Provide a mechanism to change the initial name of a fork before the fork operations is performed. If the chosen name exists in the target namespace then disallow forking (existing behavior).
More mocks
Desktop
Tablet
Mobile
Further details
Example: as a regular contributor to an open source project like gitlab-org/gitlab-ce, I have a public fork john/gitlab-ce from which I contribute improvements. Sometimes I want to work from a private fork john/private-ce when I need to fix a security issue and I can't work on it publicly. Or I might just be nervous about having my really bad WIP branches being public.
Currently this is possible using the API, or via an inconvenient workflow involving forking to a group, renaming and moving to my own namespace.
Streamlining the security release process for public projects is the primary motivation for making this easy. A developer who is going to resolve a confidential security issue, needs to be able to create a branch in a private fork. If a public fork already exists, this workflow is obstructed.
Another common use case is a template project that I want to create forks from, so that I can merge changes between projects since they are related.
Description: Forking a project allows you to have an exact copy of an original repository where you can experiment, apply changes, and submit contributions to the parent project. When forking it's useful to provide forks a meaningful name that indicates the effort or goal related to it. Additionally, having multiple copies of a fork allows you to maintain diverging projects.
This release introduces the option to edit the project name and project slug when forking, as well as the possibility of having multiple forks of the same project, allowing for different names and different forks in a single 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.
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.
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.
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?
This would be amazing to be merged along with gitlab-ce!5760 MR that I started but did not complete since it has not been yet scheduled. WDYT \cc @JobV@DouweM
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.
As requested in issue gitlab-ce#17634 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.
Had a peek at the code written by @jameshclrk and was thinking perhaps it is heading the right direction for this.
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.
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?
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'.
@DouweM what backend work is required for this? If it's mostly gitlab-ce3412464 then we should make sure we have a clear idea of the gitlab-ce24926493 so it can be tackled early so as not to obstruct. /cc @timzallmann
@jramsayProjects::ForksController#create and Projects::ForkService don't currently accept a path, but always copies it from the project being forked. We also have Namespace#find_fork_of and User#fork_of, which currently assume a user/namespace can only have one fork of a project. When a user can have multiple forks of a project, those features that use these methods to find a user's fork will need to show an actual "fork selector" to choose between the different available forks.
@winh Right, I guess one was forked, then renamed, and then the other was forked and renamed as well? It's already a wrong assumption, but doesn't affect too many people because we don't advertise supporting multiple forks. Now that we're going to start doing that, we should definitely fix it.
I found this issue, as I really want to have a base template project to fork from. I'd like to fork as if I find any errors in my template, I can easily push them back up to the main template and catch up with those changes on any other forks... so I hope this does get released.
I just stumbled on this issue myself. I also hope this gets released soon as I do not believe project templates, albeit super useful, is a replacement for forking a project to create a relationship. I think they provide a solution for different problems.
@winh thanks for the suggestion and ping on https://gitlab.com/gitlab-org/gitlab-ce/issues/47590 – I'd like proceed with this enhancement since designs are ready and it's a small iteration. There are a number of substantial epics that are looking at enhancing the project creation interface, and I wouldn't like to see this held up.
@markglenfletcher suggested in my support issue (https://gitlab.com/gitlab-com/support-forum/issues/3608) that I add my vote to this issue. We have a repo that serves as a generic template for client websites. It would be very convenient for us if the client website repos were forks of the generic template so that changes to the generic template could be easily distributed to the forks and so that pull requests could be made in the forks back to the generic template.
This is not blocking https://gitlab.com/gitlab-org/gitlab-ce/issues/58583 since it is possible to create a fork using the API or the rename trick. We should add this because it is an important improvement for lots of workflows.
@jramsay This is not entirely gitlab-ce~3412464; the Namespace#find_fork_of and User#fork_of methods I referred to in https://gitlab.com/gitlab-org/gitlab-ce/issues/13208#note_49956087, as well as User#already_forked? all assume a single fork per user/namespace, and these methods and their uses in the app would need to be updated.
@jramsay@pedroms Do we really want the "Keep fork relationship" checkbox in this interface? That seems like a pretty niche power user feature that makes this form unnecessarily complicated to someone who just wants a fork so they can contribute to a project.
For what it's worth, my company's use-case for this feature is to fork a repo so we can start a new project from the existing contents of the base repo. We like to remove the fork relationship as we don't intend to ever merge from the fork back to the parent, but use this as [as you said] a power-user feature to avoid having to create a project, clone the old repo, change the remote, publish, etc.
I have a similar use case. I'd like to create a project template and fork it at the start of a new project, so having the option to remove the fork relationship is preferred. However, if the option isn't available here, it's still possible to go into the settings later and remove the fork relationship.
Agreed. I'd like both options, but if I had to pick, I'd take being able to fork to the same group and rename over removing the fork relationship any day of the week, since that's much easier to do later on.
@jramsay understood, albeit we're not on Premium so we don't have access to those features. This workflow works really well for our team. Again, if we lose the "Keep fork relationship" option in this screen, we can absolutely live with it.
Any update on this feature improvement? Our gitlab is reaching almost 1000 repos and 300 groups. It's hard to do forks as a maintainer with access to almost all groups.
@paebbels I don't think GitLab is interested in this issue anymore. This issue was opened 4 years ago and still, they are playing around with comments. I don't know what they are waiting for. If they cannot proceed with the feature they should close this issue with rejection.
@paebbels API support was added, and we are ~"Accepting merge requests" if someone would like to contribute this improvement. Unfortunately, we haven't had been able to prioritize this improvement yet.
@andr3 since this is already supported by BE it seems we could mark as FE only correct?
@mnichols1 it seems we could reuse the "import" workflow in the mock of the issue to keep things simple (boring solution). Would love your thoughts on this.
@sean_carroll would be good to confirm we don't need BE work here. For now the assumption is you have to select an existing path/group and only the project name can be customized on the fly.
@sean_carroll Looking at the backend, I think this is mostly supported as the MR that introduced the API change added support to the Projects::ForkService which is used by both the API and the Rails controller. However the Rails controller doesn't pass path and name through in the params to that service when it's instantiated, which I think we'd need to do.
That's a very small change from our side, probably a backend-weight1.
"For me, I try to always practice any demo I plan to do. Forking a project and making a change is a super common demo. However at xxxxxxx we have a policy that you can’t delete a repo without nn hours going by. So if I fork a repo to practice my demo, then later I try to do the actual demo, when I click fork button I get an error that it already exists. I can’t resolve it by deleting the existing fork because of the nn hr policy. If I could rename on fork that would resolve the problem. So I support improving this."
Thanks for the ping @pfdistef85_git, if we progress according to plan in 13.8 this issue should make it in 13.9, however, it's too early to tell. We'll do our best to ship in 13.9, more to come.
However, the mockup in the description suggests that we may also require visibility level and "keep fork relation", along with an additional rails controller action to serve the configuration page. I feel like I should include those in this MR as well.
The mockups don't cover how to get to the configuration page from the existing "new" page (which seems to be a mix of haml and vue) - this one:
We show "go to project" at the moment when there's a fork, and assume there can only be one.
Is the plan to remove the "go to project" buttons entirely and have them all be "fork project"? "Go to project" doesn't make much sense if there's several projects.
We could consider keeping the functionality of the existing "fork project" buttons to be a "quick fork", keeping "go to project", and having an "advanced fork" button. We'd then show 1-2 buttons in each box on this page:
@nick.thomas I think those buttons all go away. The entire namespace selection as well as the groups and subgroups section is removed and replaced with mock above. Namespace selection is done through the Namespace dropdown.
It does bring up a good point, what to do with namespaces that already have a fork. I think the simplest solution is to not include them within that dropdown. Bonus points would be to show them as disabled indicating that a fork already exists, but we may want a separate issue to iterate on that.
It does bring up a good point, what to do with namespaces that already have a fork. I think the simplest solution is to not include them within that dropdown.
Maybe I'm missing something, but exactly that is what is not wanted. Should be able to have multiple forks with different name in the same namespace. See example under Further details
@jojastahl Good point 💯 I guess as long as the project name + namespace combination is unique it works. And we can handle that with error messaging on submit, similar to the create project flow.
So it sounds like we can just have the namespace dropdown include all available.
Thanks @mnichols1, I do like the simpler approach of simply showing an error message if you try to create a fork with settings that have already been used. It'd be great if we could link the existing fork in the error message, this would effectively replace the "go to fork" action.
The mockups don't cover how to get to the configuration page from the existing "new" page (which seems to be a mix of haml and vue) - this one:
I am not sure I am understanding the question here. The page shown in the mock should replace -/forks/new or you get to it via the fork button. Maybe that helps or I could be misunderstanding your question.
@andr3@sean_carroll@nick.thomas@sming-gitlab Just FYI (and as discussed in the weekly call), the mockup in the issues was based on the new project page, and since that page has been updated visually the mockup has been updated to also reflect targeting the new look of that page.
@matejlatin I think you were the designer that worked on that page update (if not can you point me to the right one). Also, just an FYI since this is targeting that pattern if you had thoughts or input or anything we should look out for. If not just a heads up.
One question - how important is the "keep fork relationship" checkbox? Could we defer it until a later issue? It's the only one that will need significant extra work in the backend to implement, and it wasn't part of the initial ask.
@nick.thomas since that option is not available today, let's defer it for a new issue indeed. I've created #299477 for that. Updated mock to reflect this, cc @mnichols1
@amandakhughes Just a heads up since we are reusing the pattern. Maybe if there were any gotchas or anything we would want to keep in mind, but otherwise no action needed.
Are you just basing the Fork project page on the New project page, or are you reusing the New project page?
@andr3 might be able to answer better, but I think the frontend was going to see if they could leverage components, but I think it will still function as its own page.
How does one enter this flow (what all links to the fork page)?
A user would click the fork button on the top of the project details page
@nick.thomas thanks for the sync call! as far as the FE, we will implement this as a Vue app -- this will allow us to better utilize our PJ components such as GlDropdown🙌
Breadcrumb Issue
One more to note is the breadcrumb. I personally prefer the breadcrumb in the old mockup. There is some rails magic that makes this happen automatically. However, if we were to implement the breadcrumb on the side (in the new mockup), we would have to build it from scratch and it will be missing some of that extra information that the rails magic breadcrumb provide (ie. project avatar image, project name). Of course, we can have that in our manual mock-up, however, it will be a bit more work and might need some additional BE work to make that information available in the FE.
Suggestion: maybe we can take an iterative approach here -- for this iteration, I suggest we leave the breadcrumb alone and move it to the side in a follow-up issue. In other words, I will proceed with the new mockup design MINUS the breadcrumb. Hope that's okay with you 🤞@mnichols1
I have !51962 (merged) open for changes to the create Rails controller action to support the new form, but we could equally use the API.
As we talked about, the new controller action will need some follow-up work, particularly around the issue of which visibility levels to show to the user for each namespace they can fork into. Just let me know when you're getting close to needing that data and I'll jump on the FE MR to sort it out.
I don't have an opinion on the breadcrumbs 😅
One last thing to note - it doesn't exist on GitLab.com, but most installations (including GDK) also have an "internal" visibility level. Just want to make sure we don't forget to include support for that level.
OK @sming-gitlab , !51962 (merged) is merged so the Rails controller create endpoint and the API now support setting the attributes you need for this page.
@sean_carroll yes, although I'm available to support in case any help is needed getting the new action / template into shape for the Vue application in !53544 (merged)
@sean_carroll I'm adding the documentation and Technical Writing labels to this issue, because this issue sounds like it will have a documentation component we need to plan for.
I also would like to provide an update on the FE 😄: I'm currently working on adding proper form validation > MR !55838 (merged). But in order for this to work, I need a new PJ component, which I'm hoping to have merged soon (it's in review now) > MR gitlab-ui!2115 (closed). And once that's done, I'll return to completing the form validation MR.
Btw, the form currently do have validation, it's just the native HTML validation > !53544 (merged).
A. I think we should wait for the proper validation MR to finish before enabling the FF (fyi, roll out issue #321387 (closed)). Which will be done next sprint. B. However, if preferred, we can also enable it in this sprint with the native validation. Not great, but it will work if we wish to have something for this sprint. I think it's best to proceed with plan A. But if plan B is better suited, please let me know and I'll get things rolling 💪 -- Feel free to chime in here with your thoughts @andr3@sean_carroll@danielgruesso🙂
@mnichols1 WDYT? (@sming-gitlab might be worth enabling it in staging for Mike to check it))
@sming-gitlab I'm wondering.. since this is in the creation of a project, we'll only be able to enable the FF globally on gitlab.com and not per-project, right? /cc @nick.thomas
If Mike agrees that it's in acceptable shape, we could roll out to gitlab.com and wait a few days for any feedback. If no huge complaints, default it to ON in 13.11 and we ship the improved validation in 13.12
@sming-gitlab@andr3 Thanks for enabling so I could take a look. I think the validation is sufficient to release now. Obviously, it will be better with the updated validation, but this is on par with many of our other forms, and in the spirit of iteration I have no objection to rolling it out.
In theory we could modify it so the subject is the project being forked - so you could see the new form if you tried to fork gitlab-org/gitlab, or any project in gitlab-org, for instance. I don't have a strong opinion on the rollout, I'd be happy with either approach.
Just let me know if you want an MR that makes the partial approach possible.
@sming-gitlab checking in - I haven't seen a first draft of docs come through, and gitlab-com/www-gitlab-com!78837 (merged) implies this is coming soon. Any word on when I'll have something I can start working from?