Thanks Job and Sytse for feedback. > > *The issue/bug(?), is a) The diffs view (Changes) view for the nonprod MR > > is incorrect IMO and differs from that of the production MR. It shows > > commits that aren't from the branch I created. I think these commits are > > always merge commits. The issue is that the diff view then shows > > changes/diffs for changes that aren't from the source branch. *These > > "extra" changes have already been merged into the target branch*. So the > > diff appears incorrect. The MR to the target production(default) branch is > > always correct/perfect. There are no extra merge commits and the diffs > > are always correct, ie just the things I changed/just the difference > > between the source and target branch. It doesn't show these extra > > invalid changes that have already been merged. *
> Showing diffs and MRs correctly should be absolutely solid, so I'm very > interested in trying to replicate this. Glad to hear so. That's what I would expect too. > Could you provide me with an example repo / a way to create one? The only repos I've seen this issue on is our two main/bigger repos. Any new repos I've created to try reproduce the issue I haven't been able to recreate the bug there. Our instance isn't internet facing so can't give access. > It wasn't clear to me from which branch you branch off and how nonprod fits > into that. Apologies, meant to mention that. Branches are created off the production branch(our default branch). production -> name_mychange. We then submit two MRs, 1 name_mychange branch to target nonprod branch and 2 another to target production. > > *b) When this occurs the title for the MR for the target nonprod will > > be set to the branch name (with the underscores stripped and the > > title capitalised.) This differs from the target production(default) MR, > > that MR title is set to from the commit in the branch. This makes the > > MR overview screen confuses because one can't easily see the two MRs > > are the same, just to a different target. * > What would be a better name in your situation? Adding information in the > title about the target branch or just providing more information in the > list of MRs / on the MR view? The question is not really which name is better in our situation. The main issue is that it sometimes picks the MR title name from the branch and sometimes picks the MR title name from the commit. So the same branch submitted to target nonprod branch, it would sometimes pick the branch name as the MR title. The same branch submitted to the target production branch, it would pick the commit log name as the name for the MR title. I would expect both MRs with the same source branch to both have the same title. Moreover when this occurs we notice the above described wrong diff. > > *How can I debug this further? Should I log an issue for this? I think > > it may be a bug in GitLab as this didn't occur while we were with > > Stash. Unless it's something we're doing wrong. * > You can always make an issue, which makes it easy to keep track of what > happened. I do think that a replicable case will be necessary in order to > fix this. Please also note your GitLab version and installation type when > you do. I'll try put some more effort in trying to reproduce this issue. Though it's difficult because it seems random and I've only seen it in our main repos. I'll create an issue for this to track it there. > *2) When submitting a new MR, the source branches aren't sorted by > last modified/updated. Therefore one needs to type in(and remember the > name) of the branch name when submitted a new MR. Rather then likely > just clicking the branch from the top of the list. Similarly other > views, like the MR Merged page, I think, should be displayed by Last > updated by default. * > > Makes sense! I think we should do it. I've created an issue and scheduled > this for a future release: > https://gitlab.com/gitlab-org/gitlab-ce/issues/14989 Awesome - thanks. I know a lot of users will appreciate this. > > *3) Stash's PR/MR view was a little "clearer". Specifically one could > > see the source branch name and the target branch name from the > > overview screen. We find this very helpful. GitLab only shows the target > > branch name, if it's not the default target branch. It also doesn't show > > the source branch name which we find helpful. * > > You mean the list of MRs? Yes. > This is a hard one! We have a lot of potential information for that list, > depending on what you use and we have to balance the amount of information > with its density. > Is it an idea to include that information in the title of the MR instead > (as suggested above)? This is indeed a hard one. Let me think about it and try log a issue for it. It's made worse by the above issue, in that the MR title sometimes differs even when two MRs both have the same source branch. I think ultimately always showing the source branch, the target branch would help a lot. Perhaps separating this information in columns would help too. Currently GitLab doesn't show target branch if target branch is the default. And it never shows the source branch name. Sometimes the MR title is the source branch name, sometimes it's the MR title is derived from the git commit. > > *4) We miss the ability to approve MRs and or require mandatory reviewers. > > However it's understandable for this to be missing in the CE edition and > > still makes the switch well worth it. * > > We'll be adding approvals using emoji to GitLab CE in the future: > > https://gitlab.com/gitlab-org/gitlab-ce/issues/13411 > For person-specific approvals, you will still need GitLab EE, but the > functionality will be greater for CE than it is now. That's very nice. I added my comments to that issue. > > *Other nice to haves: 5) We use the thumbs up/down to "approve" MRs. A > > proposal would be that when one thumbs up/down a MR it shouldn't count or > > increment the chat bubble icon on the MR dashboard view. The reason is that > > it's nice to look at the MR overview page and see if a MR is approved or > > not while being able to see if there is comments on the MR. ie > > differentiate between the two the MR overview page. * > See above and here! > https://gitlab.com/gitlab-org/gitlab-ce/issues/13411 #13411 issue may solve this one for us. :) > > *6) Having a automatically merge this at date/time would be great. As some > > of our changes (in an infrastructure as code environment) happen > > as specific date/times. * > I'm not sure if this is something we'd do, but I understand the use case. > Is at those times no one available to merge something? I'm happy to discuss > alternative solutions. I could see this being a EE only feature. I do think it would be cool and helpful to some organisations. It's a common requirement for us, as sometimes MRs need to go in at all sorts of strange times. So it would be nice to review it during normal working hours and select it to be merged automatically at "implementation time". Now our on call support person would need to login and merge the MR at the appropriate time. https://gitlab.com/gitlab-org/gitlab-ce/issues/15067 Created to track the idea. > *I'd like to log issues/proposals for some of the above. However I thought > I'd post here first and take it from there. * > > Great! Feel free to make issues at any time! Thanks a ton for the feedback and great product. -- You received this message because you are subscribed to the Google Groups "GitLab" group. To unsubscribe from this group and stop receiving emails from it, send an email to gitlabhq+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/gitlabhq/87oa9kz7sa.fsf%40santanas.co.za. For more options, visit https://groups.google.com/d/optout.
