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

List:       lilypond-devel
Subject:    Re: Process clarification regarding branches, merge requests
From:       Jonas Hahnfeld via Discussions on LilyPond development <lilypond-devel () gnu ! org>
Date:       2021-11-16 9:26:11
Message-ID: 79e2fa47194e0bf53b1efd8199fb5a0de98c1dfb.camel () hahnjo ! de
[Download RAW message or body]


Am Montag, dem 15.11.2021 um 10:00 -0800 schrieb Aaron Hill:
> I should state that I only have experience with GitHub, so I might mix 
> up terminology when trying to map things to GitLab.
> 
> Is there a preference whether development branches should be created on 
> the repository itself versus a forked copy?  What I am used to on GitHub 
> is working from my own fork, creating branches as needed, and then 
> submitting a pull request that can be merged when validated and 
> approved.  I see some merge requests for the project are coming from 
> branches within the origin repository.  Is this a policy thing or 
> something where GitLab just fundamentally works differently than GitHub?

As far as I can tell, there is no difference (anymore [1]) between MRs
coming from a branch of the same repository vs a branch in a forked
repository. FWIW I submit MRs from my fork 99% of the time, and I
personally think it could make sense to completely deprecate pushing
development branches to the "official" repository because it avoids
them turning stale and requiring us to clean them up once in a while.
(Technically they can still turn stale in a fork, but then we don't
need to care as a project.)

1: This used to be different in the past where only branches from the
same repository could use the runners configured for the project, but
now this is decided whether the person starting the pipeline (ie
submitting the MR) has permissions in that project or not. So now I
also get the benefit of the fast CI build times, as everybody else 🙂

Jonas

["signature.asc" (application/pgp-signature)]

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