Hi Simon, No it is not possible due to the use of Marge to merge patches. Gitlab automatically chooses the merged status as follows:
Consider two MRs both which target HEAD. MR 1: HEAD <- A MR 2: HEAD <- B Marge creates a batch which contains both MR 1 and MR 2. Once the batch succeeds, firstly MR 1 is merged. HEAD <- A MR 1 is closed with the *merged* status because A was merged directly into HEAD and it matches the state of MR 1. Then patch B gets merged and now master looks like: HEAD <- A <- B MR 2 is closed with closed status because B was merged into master after A, not directly onto HEAD (as the original MR was). There is no option to change this status in the gitlab API. Cheers, Matt On Fri, Jul 5, 2019 at 8:38 AM Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> wrote: > > Ben > > Still trying to understand GitLab. Look at MR 1352 > https://gitlab.haskell.org/ghc/ghc/merge_requests/1352 > > It clearly says on the first page “The changes were not merged into master” > But lower down (at the end) it says “Merged in 80af...” > > What should I believe? Merged or not merged? > > Also > > It would be really helpful if a MR status, displayed prominently at the top, > had “Merged” as a status, not just “Closed”. If I’m trying to check if my > has landed, and I see “Closed”, that could mean that someone has (doubtless > for good reasons) closed it manually, and that it will never land. > > Would that be possible? > > Thanks > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
