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
