Well I think there should be no e-mail when a MR is created - if folk are not added to the MR.
However some MRs go back into development mode [after initial reviews] - thus triggering many e-mails to the participants. So one would have to manually toggle their 'notification' setting on the MR to avoid the e-mail [and perhaps re-enable this - when its ready for re-review?] Satish On Tue, 23 Jun 2020, Scott Kruger wrote: > > > I see the value in this, but am somewhat ambivalent.. > > As a workflow, I did do the "Assign to me" and then when it was actually ready > to merge, I changed the status to "Ready to merge" and assigned to Satish. I > liked this because the gitlab MR button in the upper right shows the ones > assigned to you by default -- it's a nice To Do list. > > Of course, with your petscgitbash, effectively you can see your MR To Do list > from the command-line, and having a tidy MR list for PETSc itself is really > nice. I agree that PETSc's is a bit messy. > > However, if I'm going to get a conflict, it's almost certainly going to be > from Junchao and I like seeing his MR's just so I know which files he's > working on. (Click that MR button, clear the search with your name, change > Author=@jczhang07, and it'll appear in your recent searches so easy-peasy). > Yes, I can do a > git branch -a | grep jczhang > but there are a lot of branches there, and there isn't as much explanation as > you get with an MR. > > Of course, I could try actually emailing or *gasp* talking to Junchao, but > isn't the whole point of the internet to minimize contact with people? ;-) > > And yes, I can see it when the MR is ready, but one (admittedly generally > positive) side-effect is going to be a shorter MR cycle. > > Scott > > P.S. I await the perfect git command(s) that renders my whole argument moot > and makes me feel like a git noob. > > > > On 6/23/20 6:21 PM, Barry Smith wrote: > > > > One can test a branch with Pipelines (and fix it) before making a merge > > request. GitLab is smart enough to remember that branch has passed the > > pipeline and not require another test just because you make a MR (unless > > of course you change something based on MR feedback). > > > > This can prevent some churn in merge request messages and constant > > pushes. Of course if one needs help in fixing a pipeline problem one is > > free to make a WIP merge request and ask for help there. > > > > Barry > > > >
