Gitlab notes

[Ben Gamari]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190108/fc8c7786/attachment.sig>