Iavor Diatchki <iavor.diatc...@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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
