[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Gitlab Evaluation & Migration
From:       Eike Hein <hein () kde ! org>
Date:       2019-02-27 19:12:55
Message-ID: 80211036-4aea-ee87-c074-ed8641fcb7ab () kde ! org
[Download RAW message or body]



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


[prev in list] [next in list] [prev in thread] [next in thread]