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

List:       kde-devel
Subject:    Re: Gitlab Evaluation & Migration
From:       Nate Graham <nate () kde ! org>
Date:       2019-02-27 22:15:58
Message-ID: 16931075622.f87d7abd28944.2011509933882098627 () kde ! org
[Download RAW message or body]

 ---- On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein <hein@kde.org> wrote ---- 
 > 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. 

Thanks Eike, that makes e a lot of sense. Going to the website to fork each repo for \
the first time still adds an additional manual step compared to the status quo, so it \
would be nice if we can get kdesrc-build so set up forks automatically. That would be \
really slick.

Nate


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