Could Marge change the target branch of an MR before merging it? Perhaps this would convince GitLab to show the right info.
On Fri, Jul 5, 2019, 6:18 AM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > | You believe the one which marge posts telling you that the patch is > | merged, the commit it links to is on master so you can clearly see the > | patch has been committed. > > OK. The earlier one, also from Marge, not the Discussion stream but > rather in the panel at the top, says > > Closed by Marge Bot 8 hours ago > The changes were not merged into master > > So that is an outright lie? Yes it is closed, but contrary to the > statement it _has_ been merged. > > It's unfortunate that this misleading display is right at top, in the > summary material, while the truth (that it has been merged) is buried in > the Discussion stream. > > Alas. But thank you for clarifying. > > Is this something we can raise with the Gitlab folk? It seems so > egregiously wrong. > > Simon > > > | -----Original Message----- > | From: Matthew Pickering <matthewtpicker...@gmail.com> > | Sent: 05 July 2019 10:55 > | To: Simon Peyton Jones <simo...@microsoft.com> > | Cc: ghc-devs <ghc-devs@haskell.org> > | Subject: Re: Gitlab workflow > | > | It's not possible to make the MR status merged and also have a reliable > | merge bot. We used to try to make the status merged but it caused too > | much instability. > | > | Merge trains might eventually work but the current iteration is not > | suitable as it doesn't work with forks. > | > | You believe the one which marge posts telling you that the patch is > | merged, the commit it links to is on master so you can clearly see the > | patch has been committed. > | > | Matt > | > | On Fri, Jul 5, 2019 at 10:43 AM Simon Peyton Jones > | <simo...@microsoft.com> wrote: > | > > | > | No it is not possible due to the use of Marge to merge patches. > | > | Gitlab > | > > | > By "it" is not possible, you mean that it's not possible to make the > MR > | status into "Merged". Worse, I think you are saying that some MRs will > | say "Merged" and some will say "Closed" in some random way depending on > | Marge batching. Sigh. > | > > | > Maybe this will get better with Gitlab's new merge-train feature. > | > > | > Meanwhile, my original message also asked why the MR shows two > | contradictory messages about whether the MR has landed. Is that also > un- > | fixable? And if so how do I figure out which one to believe? > | > > | > Thanks > | > > | > Simon > | > > | > > | > > | > | -----Original Message----- > | > | From: Matthew Pickering <matthewtpicker...@gmail.com> > | > | Sent: 05 July 2019 10:39 > | > | To: Simon Peyton Jones <simo...@microsoft.com> > | > | Cc: ghc-devs <ghc-devs@haskell.org> > | > | Subject: Re: Gitlab workflow > | > | > | > | 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- d...@haskell.org> wrote: > | > | > > | > | > Ben > | > | > > | > | > Still trying to understand GitLab. Look at MR 1352 > > | > | https://gitl > > | > | ab.haskell.org > %2Fghc%2Fghc%2Fmerge_requests%2F1352&data=02%7C01% > | > | 7C > > | > | simonpj%40microsoft.com > %7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988b > | > | f8 > > | > | 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&sdata=xZZiF > | > | zO > CRNpEskjO1MVSONbDvug9dyGEQtaHHSpGeCk%3D&reserved=0 > | > | > > | > | > 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 > %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C > | > | 01 > > | > | %7Csimonpj%40microsoft.com > %7Ce03ba07f29c447c1252e08d7012c9b59%7C72f9 > | > | 88 > > | > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&sdata=2a > | > | Xm > n8ewTaA3S8y5eg0sa0lIed7L7BQRfm4jRTTvoO8%3D&reserved=0 > _______________________________________________ > 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
