Re: Question about Gitlab MR workflow.

I've added a blurb in the wiki page about rebasing MRs: GitLab usually complains that "Fast-forward merge is not possible" on your MR. If you see a green check and green "Rebase" button, NO action is necessary: your MR will be rebased automatically on merge. If instead you see an exclamation mark and disabled "Merge" button, you must rebase manually and fix any merge conflicts. - David Eichmann On 5/9/19 9:02 AM, Simon Peyton Jones via ghc-devs wrote:

It would be good to add this advice to our "how-to-contribute" pages.

Simon

| -----Original Message----- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 09 May 2019 07:46 | To: Iavor Diatchki | Cc: ghc-devs | Subject: Re: Question about Gitlab MR workflow. | | Hi, | | > About 4: I really don't understand how this rebasing business is | > intended to | > work: every time I rebase, I new CI job is fired up. But, | > presumably, while this is going, other things are going to be merged | with `master`, so I'd need | > to rebase again. So, when would I ever stop rebasing? | | Rebasing is actually not necessary. Marge adds your MR to the batch MR | when it's approved and passed the tests. It doesn't have to be based on | HEAD. So just don't bother with it. | | Only time I needed a rebase was when there was a failing test in HEAD and | a commit that disabled it had just landed. My MR was not passing the tests | because of the test so I had to rebase. | | Ömer | | Iavor Diatchki , 9 May 2019 Per, 02:19 tarihinde | şunu yazdı: | > | > Hello, | > | > I've just had a go at making a small MR on our new Gitlab system, and | > I am a bit confused about the intended workflow. I was following | > these instructions : | > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl | > ab.haskell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing-bugs | > &data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6 | > d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=UBBq5BHxuAdK | > ZRSkl3wVCCNoVC23%2FF7cUETgUQcdx30%3D&reserved=0 | > | > My question is about the steps after 2 (i.e., 3 and 4). Step 5 about | > the beer I already did :-) Here was my experience so far: | > | > 1. I made the changes I wanted yesterday over lunch: the change was | > quite trivial, I added a NOINLINE pragma and some comments and I mage | > the MR. | > | > 2. Sometime in the evening (half a day later!) I got an e-mail from | > the CI system that something had failed. It was quite hard to tell | > what had failed, and after poking around at the logs, it seemed like | > it was some sort of spurious failures because things had timed out, I | > think? | > | > 3. Today I got some feedback from a reviewer about some changes I | > should make to the MR. As I was working on those, I noticed that | > every time I push to the MR, the CI is forking a new job. I cancelled | > some of those manually, to save on resources, as they already seem to | > be taking half a day. | > | > 4. After making the changes, I noticed that Gitlab is asking me to | > rebase my changes because, presumably, some other things have already | > been merged. It is easy enough to rebase my MR, but every time I do | > so, this fires up a new CI job. And, of course, this is going to | > keep happening, until I am lucky enough to rebase just at the right | > time? This doesn't seem right. | > | > So my questions are specifically about step 3 and 4: | > | > About 3: wouldn't it make more sense to start firing up CI jobs | > only after an MR has been approved for merging? | > | > About 4: I really don't understand how this rebasing business is | > intended to work: every time I rebase, I new CI job is fired up. But, | > presumably, while this is going, other things are going to be merged | > with `master`, so I'd need to rebase again. So, when would I ever | > stop rebasing? | > Furthermore, in my case the rebase is trivial, but with a larger | > patch, doing multiple rebases seems like a lot of wasted work. | > | > Any help would be appreciated! | > | > -Iavor | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs@haskell.org | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=01%7C01 | > %7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6d44a2702%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1&sdata=wf4URw4jefgMCuXKtJMrTzTB4V2TJ | > i%2F6%2F5uwfAdypps%3D&reserved=0 | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6 | d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=wf4URw4jefgMCuXK | tJMrTzTB4V2TJi%2F6%2F5uwfAdypps%3D&reserved=0 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England