Thanks Divan for your kind words, glad to hear GitLab is a major upgrade for you! I've asked Job to respond to your comments.
On Monday, April 4, 2016 at 9:44:45 AM UTC-4, Divan Santana wrote: > > Hi All, > > So I thought I'd post about our experiences switching from Atlassian > Stash to Gitlab CE at a banking institution from South Africa. As well > as ask some questions). > > I think GitLab as a product and how the company is run, is simply > awesome. Enjoy reading the blogs and the "openness" of the company. I > also like the idea to try put as much data/content under git and GitLab > control. > > So we decided to switch away from Stash (which we were paying for) and > switch to GitLab CE. Unfortunately some departments are still running > with Stash (and the various Atlassian products) but at least our > division isn't. > > The good: > > There is a lot. But some of the highlights for us have been: > > 1) It's blazing fast compared to Stash. It's like comparing a cheetah to > a turtle, seriously. In our case the turtle was also sick, and would > often time out and or have errors. Moreover the merges are kind of > asynchronous in GitLab compared to Stash where they appeared synchronous > and one would have to wait for each MR to > > 2) Omnibus is really great. There are so many reasons why we've found > omnibus great. > > - We can and do automate the updates of GitLab nightly via > apt-get. > > - Really quick and easy to get it up and running. And one can feel > confident it's well configured. > > - The software stack gets updated too with GitLab updates. > > 3) Way more KISS solution. In every way. Which encourages users to use > the system more as well as makes sysadmin of the system easier too. > > 4) Being able to revert merges (not just commits) and via the web > interface is really nice. > > 5) RSS by default, nice stats integrated, WIP feature, milestones, > TODOs, integrated issue system, syntax highlighted diff etc. > > 6) Admin impersonate feature. This is really helpful under various > scenarios. It also helped with the migration. > > 7) Single page to view all MRs. This simple and crucial feature was > missing in Stash. > > 8) System resources. Before we had multiple nodes with beefy virtual > hardware. We now have one relatively low spec VM on vplex which performs > great as is HA enough for us. > > 9) Frequent/rapid development of GitLab :) > > 10) Documentation is simple and great. > > 11) The community focus and openness of development. > > 12) It's completely free software! (CE). > > > The drawbacks since switching from Stash: > > 1) > (This one is major for us. This may be a bug or perhaps it's something > we're doing wrong. I'm really not sure and have no idea how to debug > this further. So any tips here would be appreciated. I may go ahead and > file an issue if need be.) > > The way our git process works is we have two long standing branches, > nonprod and production. We create new branches off production typically > make the change in the new branch and submit two MRs, one to nonprod and > one to production (which is selected as the default in the project). > > 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. > > 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. > > I unfortunately can't consistently reproduce the issue, it happens > randomly. The above description is what happens when the issue occurs. > > 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. > > 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. > > 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. > > 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. > > > 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. > > 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'd like to log issues/proposals for some of the above. However I > thought I'd post here first and take it from there. > > > Summary: > > The actually switch from Stash to GitLab CE was also very easy and > problem free. > > Overall, switching from paid for Stash to the free GitLab CE has been an > a wonderful *major upgrade* for us and made our working environment so > much better. It's a pity we never switched earlier. > > Thanks to all and keep up the great work. > -- > Best regards, > > Divan Santana > > -- > Best regards, > > Divan Santana > > Red Hat Certified Architect > > RHCA | CCNA | MCSE > > Mobile: +27 82 787 8522 > Email: di...@santanas.co.za > -- 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/c1257d12-ac7f-4050-8a6e-7caf8e317ce7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
