GitLab 8.13 Released with Multiple Issue Boards and Merge Conflict Editor | Hacker News Reader

GitLab 8.13 Released with Multiple Issue Boards and Merge Conflict Editor

about.gitlab.com

154 pointsSmibu48 comments

Speaking of UX, would you consider improving the look of Markdown rendered text (usually README.md) in the repo browser? On GitHub they look great and it's a pleasure reading Markdown formatted text there. In GitLab it's however not very appealing. Headers, spacing between them and paragraphs doesn't look very good IMO.

Coming from a previous job where we used GitHub and TeamCity, something I miss with GitLab is the ability to create a pipeline that's not connected to a specific Git branch. I'd like to be able to create a pipeline that can be triggered manually, without first having to create a dummy branch to put a .gitlab-ci.yml there. Is that something that's on your roadmap?

Regarding Markdown renderering, from my perspective the most important improvement is reducing the line width to a better readable character length. This is already addressed [0] and on the list for the 8.14 release. I agree that the spacing can be improved. In general, my impression is that there is a good awareness for required UI improvements [1] in the GitLab team. So I’m looking forward to the upcoming releases.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/13680

[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/22192

Thanks for posting Andreas. If there are other concrete things we can do to improve markdown rendering issues for them are very welcome.

I find the whole design of GitLab not appealing to my eye. The recent redesign was a step in the right direction but I am still missing visible separators (e.g. boxes, lines, colored background) between/around areas for example on the page of an issue.

I have to agree. When I first started using Gitlab, it was quite jarring.

I'm much more happy with Gitlab's UI now that I've spent a lot of time with it. At least I don't fight with the interface after becoming familiar with it (it's no iTunes).

Thanks for the feedback, and I'm sorry to hear about the issues. We will continue to iterate and improve upon the design of GitLab based on feedback, and I hope we will address your concerns.

UX (and performance in general) is the #1 reason we don't use GitLab.

Another release we're very proud of. Much of the work this release we spent on improving our idea to production flow and demos [0], things that'll trickly in over the coming releases.

We're also focusing on some longer-term improvements in UX [1], and are happy to ship some nice iterations with issue boards and merge conflict resolution.

Lastly, we're slowly building up review apps, which allow you to see/play with/test your changes running in a live environment. A very powerful concept and one we hope we can bring to everyone.

As always, we're here for any questions.

[0]: https://about.gitlab.com/2016/08/05/continuous-integration-d...

[1]: https://about.gitlab.com/2016/10/19/gitlab-ux-update/

review apps are super exciting! That's the exact kind of interface I've been hoping for. I really hope it's available like the commit status api is (we use that for posting our custom CI builds). We currently have our own review app system at our company (and no hopes of switching to gitlab ci in the future - unfortunately :( ), but it'd be amazing if we could tie into it the same way we do for CI -- just "here's the link, it built succesfully!" would be a huge improvement to our workflow. Currently we treat it as a separate build (posting to status, with the url being the review app). Then because the URL didn't seem very visible on gitlab, we post it in the merge request too. Not nearly as nice as this would be!

Review apps are 'just another GitLab CI job'. But you can now set an external url in every environment. Every review app will have an environment create for it and you can add the URL there. I'm not sure the external url is in the API yet, but if not it is a question of time.

Thank you so much! That's amazing to hear. I think that will work for us. And as always, thank you for being one of the most outward communicating CEOs!

My pleasure!

I am continuously blown away how quickly Gitlab is pushing out releases. It's been amazing to see the product grow over the years.

Thanks, glad to hear that! To see where we're going the rest of the year please see our vision demo https://about.gitlab.com/handbook/sales/vision-demo/

Having a lot of issues with our merge requests never merging and just spinning forever.[1] Would like Gitlab to put a little more focus on those kinds of dealbreaker issues. Would hate to give up such a great product because of things like that.

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/2995

Thanks for posting, I mentioned one of our issue triage specialists in the issue.

Great! Responses like these really make me like you guys :)

I followed up with you on the issue :)

Since the GitLab folks hang around here... any chance you'll let us force a redirect to HTTPS for GitLab pages with custom domains? Loving GitLab so far though!

Our documentation is on https://about.gitlab.com/2016/04/11/tutorial-securing-your-g... but if I understand correctly we allow https but don't enforce it? That sounds like a great idea, I created an issue in https://gitlab.com/gitlab-org/gitlab-ee/issues/1147

Please fix the speed. Even your gifs are slow.

Plenty of work is being done in terms of performance improvements, and almost every release features a large set of improvements. A list of all performance related merge requests that have been merged can be found at https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope....

If you'd like to help out you can read up on the contributing guidelines at https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU....

Alternatively, any issues with data on what is slow and how these patterns can be reproduced is also greatly appreciated!

We're working hard on making GitLab.com faster (where I also made the gifs) [0]. If you're running your own instance, it should be fast.

[0]: https://gitlab.com/gitlab-com/infrastructure/issues/59

The slow loading of the community pictures in the background of the gitlab landing page (about.gitlab.com) gives the impression that it's very slow even if the relevant content on the page loads much faster. At this point Gitlab has a reputation for being slow so fighting this has to also be done at the perception level; not only ttfb level.

Yeah, a few folks mentioned the hosted version is fine. However, I am not interested in hosting my own instance. That's said, I don't mind paying a small monthly fee if it means getting a faster cloud service on less crowded servers.

In that case https://githost.io/ might be interesting for you. private managed instance of gitlab.

Yeah, the feature set might be good (better than GitHub, I don't know), but every time I try GitLab or use Bitbucket, they're just so sluggish compared to GitHub it puts me off. Edit: I just tried GitLab again, and it looks like they've made good progress in this area -- still seems significantly slower than GitHub, but it's no longer dog slow to just browse source code.

We run GitLab via the omnibus package in our data centre on a modest VM and it's no slouch (2 CPU, 8GB RAM with ~15-20 users and about 10 active projects). The hosted option isn't the fastest, though.

We deployed GitLab just a few weeks ago in our setup and we can already see its impact on our development process.

Sometimes GitLab becomes extremely slow. A few days ago it became so slow that we had to check what was wrong and we found that a process named "bundle" taking up too mach memory and CPU. As we do not have a lot of experience with GitLab we could not figure out the reason behind "bundle" process eating up memory and CPU and therefore we tried restarting GitLab and everything was fine again.

If only they could include sub-tasks it would be perfect for our team.

> New Issue from the Issue Board

Finally. I missed this so much. Loving the work GitLab is putting in to their product.

Now, if only I could rearrange backlog items.

I'm thinking we're going to do this as the next change to the issue boards, before anything else [0]. I'm aware everyone wants this and it makes total sense.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/21264

Does this release also support rendering Jupyter notebooks like github does?

We are currently in the process of finding ways to implement many formats more quickly. It's certainly on our radars, although I can't promise it will make it into the next release.

I'm actually not sure if we do. Can you share me a link to an example? Seems like something very GitLab-esque to support.

Rendered: https://github.com/stitchfix/Algorithms-Notebooks/blob/maste...

Raw: https://raw.githubusercontent.com/stitchfix/Algorithms-Noteb...

Looks like the issue [0] had a milestone of 8.13 but it is still open. So, it didn't make the release?

[0] https://gitlab.com/gitlab-org/gitlab-ce/issues/2508

It didn't make it, I've asked our VP of Product to assign a new milestone.

Would it be possible to make the Board view default view when going into issues via some option?

We already have some default views that you can set, feel free to create a feature proposal to add one for this.

not impressed with Merge Conflict Editor, would be a lot better as visual diff with two versions next to each other (ala meld), not to mention arrow buttons to quickly pick version without touching text.

And squash merge is still an ee-only (paid-only) feature ¯\_(ツ)_/¯

I do not understand the appeal of squashed merges. The only pro i know of is the ease of reverting a merge. On the cons side: you obfuscate an entire branch into a single commit, effectively making git-bisect useless. Furthermore, if multiple people collaborate on a branch, all code blames to one person, quite literally rewriting the code history.

Its designed more for people who do master-based development and do a PR per commit. (But might add a couple commits fixing the PR)

It's going to be highly pipeline, workflow, and team interaction dependent. In my place of work you generally only have one person working on a branch to add small, modular features. For releases we cut master into release branches. We fairly frequently need to downstream a commit from master into the staging branch and more rarely the production branch. The squash allows for a quick and easy cherry-pick of the feature to apply downstream.

If the code change is not widespread, I would always encourage a squash. Commits to two different parts of the codebase that do not directly rely on each other on the other hand should remain separate.

Squash merge would be most useful in cases where someone turns in a PR and then there's back and forth which result in them making additional commit such like "Fix typo" and "Change struct name". That's not useful history and it's sometimes easier just to squash merge rather than give the contributor a lesson on reabse every single time. Naturally you shouldn't squash if the history needs to be cleaned up manually but it's rare to have multiple authors on one PR.

What does this actually mean? Does their UI just fall apart if you force push after squashing in git rebase -i?

actually they always merge via -no-ff. and time tracking in issue's is also a ee only thing. actually the last releases were pretty much focused on ee-only stuff, it's sad that it will be more closed caused by the money.

Reply on news.ycombinator.com