111–120 of 128 posts
This is awesome. Is it possible to have a central set of issues per group? Many (real-world) projects have issues that span across multiple (GitLab) projects. I guess one could create an "empty" project for issues, but this is hacky. Thanks again.
8.11 overhauled the diff backend, which works great! But the front-end still chokes up and freezes because the default appears to be 1000 files worth of diffs. This still pegs my CPU and hangs my browser when the page tries to render.
The second time loading the page is always fast (maybe something caches somewhere), but the first time is slow and chews the heck out of my poor PC. :(
Any chance we could get some sensible limits on the amount of information shown in a diff? Nobody is going to wade through 1000 files of diff in a web browser, so there's no reason to jam things up trying to render it.
https://gitlab.com/nrclark/dummy_project/commit/81ebdea5df2f...
edit: also, clicking the "Plain Diff" button breaks Gitlab
Earlier quoted context omitted.
Gitlab's in-project navigation recently changed, Everyone on my team was confused.
We know that navigation redesigns are confusing. But we want to keep iterating to make it better. We explained the reasoning behind the change in https://about.gitlab.com/2016/06/06/navigation-redesign/
The only thing that confuses me and my coworkers about the new design is the decision to hide the left navigation bar behind a hamburger menu by default. It's great that we can pin it open now, but why hide all of that useful navigation behind an ambiguous, easy to miss, unlabeled icon?
Earlier quoted context omitted.
We know that navigation redesigns are confusing. But we want to keep iterating to make it better. We explained the reasoning behind the change in https://about.gitlab.com/2016/06/06/navigation-redesign/
Almost all of the navigation redesign was excellent. The information hierarchy was made much clearer. The only thing that confuses me and my coworkers about the new design is the decision to hide the left navigation bar behind a hamburger menu by default. It's great that we can pin it open now, but why hide all of that useful navigation behind an ambiguous, easy to miss, unlabeled icon?
I have yet to understand where this kanban board stuff makes sense. Apparently, the Agile philosophy [0] introduced this to the software development world. Most implementations (Gitlab, Wekan) seem to miss central features (limits, cycle time stats). I guess those boards serve as a issue tracker extension for short term development? How does that improve the process? Why do you need that on top of an issue tracker? R…
It complements the existing issue tracker, the issues and the labels are the same. You can use issues without the board but it might be useful to give a visual overview. In meetings it is frequently easier to use a board see the many issue at a glance and to drag and drop them. I'm not sure we want to have the software enforce limits, but I do agree that you don't want any list/column to become too long. Cycle time a…
Gitlab has a really great set of features and I appreciate the open and professional development style very much. It's very resource-hungry, though. At one point I just gave up and switched to Gogs. Less features, sure, but very fast, even with many users.
Yeah, if you want to use less resources Gogs is a great option. Did you know out team member Kim works on Gogs fulltime? https://about.gitlab.com/gogs/
Gitlab has a really great set of features and I appreciate the open and professional development style very much. It's very resource-hungry, though. At one point I just gave up and switched to Gogs. Less features, sure, but very fast, even with many users.
Yeah, if you want to use less resources Gogs is a great option. Did you know out team member Kim works on Gogs fulltime? https://about.gitlab.com/gogs/
Earlier quoted context omitted.
Yeah, if you want to use less resources Gogs is a great option. Did you know out team member Kim works on Gogs fulltime? https://about.gitlab.com/gogs/
Fascinating. I'd understand why GitLab and Gogs might not be competing with each other, but why invest in Gogs? How does that benefit GitLabs the company?
Joking aside. Most likely to get a foot in the door on competition and on git related features written in Go, which might supplement or replace parts of the infrastructure within Gitlab. They already use Go for the CI runner part and as a smart, Gitlab aware proxy.
Gitlab has a really great set of features and I appreciate the open and professional development style very much. It's very resource-hungry, though. At one point I just gave up and switched to Gogs. Less features, sure, but very fast, even with many users.
Yeah, if you want to use less resources Gogs is a great option. Did you know out team member Kim works on Gogs fulltime? https://about.gitlab.com/gogs/