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
--
Tech-X Corporation [email protected]
5621 Arapahoe Ave, Suite A Phone: (720) 974-1841
Boulder, CO 80303 Fax: (303) 448-7756
