I've said this before, but one huge thing you guys could do that would draw in a lot of companies to Gitlab EE is if you supported custom issue fields [1][2] with various field types. That feels like a pretty logical place to go from here, so I hope you guys are strongly considering it.
[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/8988 [2] https://gitlab.com/gitlab-org/gitlab-ce/issues/14884
Any idea of when we'll get global search? For a long time I've been wanting to search for a particular code snippet or file name across all projects.
/me wanders off to update
I'll often check out software, notice something small that I can easily fix, and spend 5 minutes fixing and testing it. But then I have to spend another 5 minutes going on GitHub, forking the repository to my profile, going back into my shell, changing the URL for origin, pushing the change, going back to GitHub, creating the pull request on the project, and then going back to my profile and deleting the fork that I have no interest in maintaining. This should be so much easier.
That being said, I run Gitlab under a small docker box and I couldn't be happier with it. It's so darn easy to setup. Grats to gitlab team.
~/src/bar (foo =)$ hub pull-request
https://github.com/foo/bar/pull/5
There is also `hub fork` and others: These GitHub commands are provided by hub:
pull-request Open a pull request on GitHub
fork Make a fork of a remote repository on GitHub and add as remote
create Create this repository on GitHub and add GitHub as origin
browse Open a GitHub page in the default browser
compare Open a compare page on GitHub
release List or create releases (beta)
issue List or create issues (beta)
ci-status Show the CI status of a commithttps://about.gitlab.com/2016/08/22/gitlab-8-11-released/#mr...
A patch is a unit of change. Historically, that's the type of unit that the open source world has operated with. The only reason we're having this conversation right now is because GitHub decided to build on top of pull requests instead of patches for lock-in reasons. GitLab has no such motivations, so it's silly to continue following them, especially since Git has had native support for patches from the beginning.
Just support patches already.
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? Replacing the issue tracker is probably not idea?
Each week we meet with project owners (somebody at the client company). They give us a list of tasks they want completed this week and we go over tasks we finished last week.
After the project is done, we move to only working on one-off issues they send. Usually bugs or small new feature requests. A simple issue tracker would work fine here, but we still have weekly meeting with our boss to show that we actually did work last week.
We already use self-hosted GitLab for our code, so I want to try out this new board feature to see if it meets our needs.
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 analytics are planned in https://gitlab.com/gitlab-org/gitlab-ce/issues/20975
In terms of product/features, GitLab is so much better than GH though.
We've been working on making it easier for the entire development team to collaborate and give them the right information at the right time. Here is a selection of features that I think you will find useful:
JIRA's Release Hub, to let you know if you're ready to release or not: http://blogs.atlassian.com/2015/04/jira-6-4-release-confiden...
The development panel, to turn every issue into a dashboard for it's development work: http://blogs.atlassian.com/2014/03/visualize-development-jir...
Automated issue transitioning, because it's easy to forget to move that issue to "In Review": http://blogs.atlassian.com/2014/08/jira-6-3-untangle-develop...
Hope this helps. For a good overview, you can also take a look at the documentation that outlines the above integrations: https://confluence.atlassian.com/display/BitbucketServer/JIR...
Plus the GitLab team has just been killing it with each release, and it just feels good to use open source (and be able to open issues, vote on improvements, track changes for the upcoming release...). Free private repos is just icing.
Setting up a project for both just takes a few initial commands to configure git:
git remote set-url --add --push origin git@github.com:account/repo.git
git remote set-url --add --push origin git@gitlab.com:account/repo.git
Then pushing to origin will always push to both. I also add a github and gitlab remote in case I only want to push to one as well.Are you doing a read only mirror to GitHub for this?
Code Climate can still happily read from the GitHub project and I can add the badge to the README if desired, which is visible on both GitLab and GitHub.
And since origin pushes to both, they are rarely if ever out of sync.
And by using GitLab I get GitLab CI instead of Travis (which is quite nice), GitLab's amazing Issue tracker and board, which blows GitHub away, more fine grained control over merging (no more forced --no-ff merges if you don't want), Issue and MR templates, an activity stream, far more control over your project's settings... really I can't say enough good things about my experience with GitLab over the last ~6 months.
Question: I would like to migrate from Github to Gitlab, but can not really move. Is there some bridge, which would mirror Github repos (with Issue tracker and pull requests) on Gitlab?
This is just in terms of ripping off the band-aid. I'm not sure of any mirroring, but I don't think that would be worth the hassle.
* merge conflict resolution: It definitely looks cool and make conflict resolution BY MERGING easier than any other way i know BUT most of the time I want my co-worker to resolve conflict BY REBASING (i.e as if they had branched just right now) , following the principle that you merge from specific to generic. So though I definitely agree most of people don't care, but for larger team/project where you often need to make archeology and dig inside the commit history , the "master merged into feature branch" makes the commits tree look weird
Outside of this, it's maybe only me, but most of the team I've worker with where using a scrum-like taskboard (like http://taiga.io ) instead of a kanban-like, is it planned to be added/provide the option or (which I perfectly understand) do you plan on focusing on kanban and letting third-party project for those who prefer scrum ?
As for the Kanban board, as far as I can read in https://www.cprime.com/2015/02/3-differences-between-scrum-a... the only difference with a scrum board is that you can set a maximum number per list. Feel free to create a feature proposal for that, I've already heard that request before today.
As for resolving conflict by merging, thanks I didn't know EEhad this feature.
We're always trying to promote this idea of "don't sell the product, sell the problem you're solving" and your opening statement completely tips that on its head.
Not knocking GitLab in any way, I love your product and have used it for a while. Amazing work. Just me being a pedant ;)
They're using "issue" as in "issue tracking", not "issue with how the world works". In this sense, you take an idea and write it down as an issue, which can then be discussed and implemented.
I've actually just lately been looking into a new all-in-one package like this for our company. Git hosting, code reviews, issue tracking, wiki, and nice project management features all in one place. My current systems-under-test are Phabricator and Jira.
Anyone have an opinion on how GitLab compares to those two?
Like all of our website (and our product, as a matter of fact), we accept merge requests to improve that page: https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/sou...
I'll see if I have time to evaluate yet more tools very thoroughly , but if I look into GitLab I'll definitely hit you with something for that page :)
one thing that jumps at me from those comparisons is that mostly all of them are against other tools that are mainly for repository hosting. Is it intentional, and similarly the main idea of GitLab itself?
For my 2¢, it would be really great to see some "official" love for Haskell at GitLab :) E.g. having Haskell tools installed on shared runners would be pretty nice!
I'm also curious to know the state of functional programming at GitLab. I know you guys mostly do Ruby, but would you be open to employees using functional languages or frameworks for work? (e.g. Elm, Elixir, Haskell and other exciting functional stuff)
I <3 Gitlab
Back when we built one of ZenHub’s [1] first features — task boards inside GitHub — we believed strongly that development teams needed a single source of truth in order to move faster and communicate better. That belief has underscored everything we’ve built since. It’s awesome to see further validation for this philosophy here with Gitlab!
# Why
/milestone %milestone
/label ~foo
# Instead of
/milestone milestone
/label fooUsing those characters also enables autocomplete in the Markdown textarea.
In the web interface, they are very convenient, but they are not required, so when using slash commands with reply-by-email, you can leave them out and write exactly what you have under "Instead of"
For example, I'm active at a small non-profit computer shop at the campus of my university, and we develop our own stock managementsystem inhouse. This would be a very interesting feature even for non-enterprise users like us, because that'd allow for easy code reviews without having to fork the repo.
Also noticed the speed/performance improvements lately.
Great job, GitLab!
Just need some data on the latency and reliability. so far, I only found https://status.gitlab.com/. need some historical data now.
Would love to hear your feedback and suggestions for improvements.
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