Web lists-archives.com

Re: Gitlab Evaluation & Migration






On 2/27/19 4:38 AM, Nate Graham wrote:
It's really pretty nice. But  Gitlab has a fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, people without commit access won't just be able to start hacking with the source checkout that kdesrc-build downloads, or else they won't be able to push their branch to any remotes and create a Merge Request.

No, this is not correct.

When you have a local git repository (be it your own or a clone), it can interact with any number of remote git repositories.

When you do `git clone <something>`, git automatically adds <something> as a remote named "origin" to the local repository. But what "origin" points to can be changed at any time, or other remotes with other names can be added for pushing too. "origin" is just a convention.

I.e. someone can totally do this:
1. use kdesrc-build to clone stuff
2. git checkout -b feature to make a feature branch
3. hack
4. make a private fork on gitlab
5. push to their fork from the clone they've been working in

It's not necessary to fork first and clone your fork to get started.

When I do a private fork of a repo on the existing git.kde.org (if you look at the manual, we actually do have that, albeit called "personal clone" in the docs) I usually keep it as a second remote in my clone of the main repo, too.

Since the URLs of forks in GitLab are predictable (provided the username is known), we could have kdesrc-build do that automatically. It could also add some sort of contribution script or hook for that matter to each clone, if we want more automagic.


Takeaway: It's pretty important that if we decide to migrate to GitLab, we should schedule and plan it in a way that allows us to come together and consider and debate what it would mean, what would happen, and what needs to be prepared for it. Things like the contribution workflow and the docs for it would need to be ready. The Onboarding sprint might be a good venue for that.


Cheers,
Eike