Gitlab notes

[Alec Theriault]

Hi all,

Could someone sketch out somewhere roughly what the steps are two getting something merged on Gitlab?
Here’s my current understanding:

1. You’ve implemented something and open a MR, CI starts running
2. Looking both at passing CI and at your code, someone with commit bits eventually decides to accept the MR
3. You rebase onto latest master (since we want a linear git history)
4. CI passes again, and your MR ends up in master

However, if someone else finishes step 4 after you start step 3, you’ll need to rebase again (and CI needs to run again), right?
IIRC, Rust solves this with a merge queue (where CI rebases and tests each dequeued PRs, one at a time, merging into master only on successful CI).

I’m all a bit muddled and I’d prefer not to waste the very helpful CI resources. How are things supposed to work?

Thanks,

Alec

> On Jan 8, 2019, at 8:51 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Iavor Diatchki <iavor.diatchki at gmail.com> writes:
> 
>> One other thing:
>> 
>>    At least on Github, using the button on the site to merge a request
>> always creates a proper merge (not a rebase), so the history won't be
>> straight if we do things that way.  I believe the reasoning is that in this
>> way, you have record of who did the merging.
> 
> I agree with Simon that the best model for a project like GHC is to
> maintain a linear history. Bisection becomes incredibly difficult otherwise.
> 
>>    I am not sure if this holds for Gitlab, but we should look into it, if
>> we want to keep the straight history.
>> 
> Our GitLab instance is configured to only allow fast-forward merges.
> GitLab prompts you to rebase if this isn't possible (even allowing
> trivial rebases to be done via the web interface).
> 
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs