Moving to GitLab: Yes, it's worth it • Hacker News Board

Re: Moving to GitLab: Yes, it's worth it

#151

Post by 0x0 » Fri, Aug 05, 2016, 2:28 PM UTC

bovermyer wrote: post #107

btcmike wrote: post #100

Earlier quoted context omitted.

I did the same last month and then transferred back to bitbucket. The response time on gitlab.com was painfully slow. That extra 2-3 seconds waits for each commit was enough to drive me back. I still use github for professional projects and bitbucket for personal ones.

I had the same experience. The other thing I would add is that the social side of Gitlab is not as refined as GitHub's. There's no "timeline," for example. I pay for GitHub and enjoy it.

On the other hand, gitlab's "network" view of commit branches is excellent and I've never been able to find anything remotely similar on Github. Essential to manage development in multiple concurrent branches.

Re: Moving to GitLab: Yes, it's worth it

#152

Post by jobvandervoort » Fri, Aug 05, 2016, 2:29 PM UTC

mrmondo wrote: post #149

As I always say on every GitLab post on HN (and no I'm not paid to nor do I have any affiliation with the company) - we switched from a combination of Github + Gitolite/Gitosis to GitLab not long after it was release and my god it's damn good, It's really impressed us particularly in the last 12 months how rapidly they're developing the product and getting new released / fixed / features out. Especially like Gitlab C…

Thanks, always great to see you here!

Re: Moving to GitLab: Yes, it's worth it

#153

Post by pille » Fri, Aug 05, 2016, 2:29 PM UTC

cloverich wrote: post #129

pille wrote: post #121

Earlier quoted context omitted.

Maybe she actually could've read the text and figured it out herself before sending out the note? Just firing off a warning based on a simple text match seems high-handed and/or incompetent enough to consider leaving.

Just to be clear, you're saying: "If large company x hires a single incompetent person, that is a good reason to never deal with said company again." I think that's the parents interpretation of OP and hence the "seems like a disproportionate response." (I agree it was absurd to flag the content).

That's oversimplification. Even if it is just her own personal incompetence, if GitHub just hired her and let her loose as some kind of independent repo ombudsman to scold users, then yeah, that's a terrible management decision that warrants reconsidering your relationship with them.

Re: Moving to GitLab: Yes, it's worth it

#154

Post by Karunamon » Fri, Aug 05, 2016, 2:29 PM UTC

lima wrote: post #148

Karunamon wrote: post #142

Earlier quoted context omitted.

I have this problem too. It's not hard to set up, there are just so many tiny pieces that need to be run by hand that it's going to take a human well over an hour to read through the docs and get it right. Someone made a Saltstack state[1] that I've used and had some success with - installing and configuring Salt from zero and using this config is still faster than installing Phabricator by hand. [1]: https://github.…

It's actually much easier to setup and operate than GitLab with its massive dependencies. Also a lot faster.

Gitlab is unfortunately a pig, in the large and bloated sense of the term. Which is really sad! I love the app, it looks better than Phabricator and does so much more, but then I can throw Phabricator on the same droplet I use for plenty of other stuff with resources to spare for $5/month, where Gitlab would require a dedicated $10 instance just due to memory usage alone.

Guess I'm just not the target audience :(

Re: Moving to GitLab: Yes, it's worth it

#155

Post by jobvandervoort » Fri, Aug 05, 2016, 2:30 PM UTC

lima wrote: post #148

Karunamon wrote: post #142

Earlier quoted context omitted.

I have this problem too. It's not hard to set up, there are just so many tiny pieces that need to be run by hand that it's going to take a human well over an hour to read through the docs and get it right. Someone made a Saltstack state[1] that I've used and had some success with - installing and configuring Salt from zero and using this config is still faster than installing Phabricator by hand. [1]: https://github.…

It's actually much easier to setup and operate than GitLab with its massive dependencies. Also a lot faster.

Setting up GitLab can be done through our repositories quite easily nowadays. It boils down to: apt-get install gitlab-ce

Re: Moving to GitLab: Yes, it's worth it

#156

Post by scaryclam » Fri, Aug 05, 2016, 2:31 PM UTC

favadi wrote: post #138

krautsourced wrote: post #32

I really liked Gitlab when last I tried it, but in the end I went with https://gogs.io/ instead. For a small-ish team this felt like the most straight forward self-hosted solution. Still missing LFS though, which sucks, but it's being worked on.

Last time our team tried gogs, it is unusable. Some very important features are missing: - code review - deployment key And the builtin SSH server will randomly hang once or twice every day.

Gogs has had both those for quite some time now.

We did a comprehensive internal review of both gogs and gitlab. Gogs was a long way ahead of gitlab in terms of stability/speed and had pretty much all of the features developers tend to need.

Re: Moving to GitLab: Yes, it's worth it

#157

Post by cm3 » Fri, Aug 05, 2016, 2:32 PM UTC

lima wrote: post #144

cm3 wrote: post #93

Earlier quoted context omitted.

If only phab didn't insist on squashing a patchset into a phabricator-commit, losing the carefully created history of a branch. Cumulative mega-patches are of little use when bisecting or trying to understand how a change works by being able to follow the steps to reach the final diff. A good commit history with separate commit messages explaining the diffs goes much further in allowing someone else to understand a c…

You can disable the squashing. It's a common complaint. https://secure.phabricator.com/book/phabricator/article/arca... > Phabricator could easily include their metadata in a merge commit And this is what happens :-)

Thanks for the link. As arcanist is the php-based client to speak to Phab, does this mean it's a user setting only and is fully respected by Phab, meaning it's something set on first publishing of a diff and kept in that setting? Is this also possible when submitting a diff via the web interface?

What's funny is that mutability didn't exist for Mercurial support because when it was written Mercurial had no official mutability feature.

And I can only suppose mutability being default for git support is because of Facebook's dev style. It's wrong to assume that those who want merge commits for the final merge onto master do not rebase locally before sending a pull request. Rebase is a standard tool for working on your branch (aka patch set aka patch queue) and it's normal to rewrite it upon each revision of the branch sent for review. Does phab support multiple revisions of a branch in one diff or does it require separate diff tickets? This is something that Gerrit got right, allowing one to see the diff between revisions of a branch (patchset).

Re: Moving to GitLab: Yes, it's worth it

#158

Post by pjc50 » Fri, Aug 05, 2016, 2:34 PM UTC

OliverJones wrote: post #9

Working for a 15-year old small software company, I converted a whole bunch of ancient CVS stuff (yeah, yeah, don't laugh unless you also have 15 years of profitability) to GitLab CE. After a couple of false starts it went flawlessly and now works flawlessly. (I used the tigris.org migration tools). The GitLab team is doing a great job. Thanks you guys.

How about 20+ years of operational history from SCCS: http://fanf.livejournal.com/132656.html

Re: Moving to GitLab: Yes, it's worth it

#159

Post by dvdgsng » Fri, Aug 05, 2016, 2:39 PM UTC

marcinkuzminski wrote: post #46

mikro2nd wrote: post #11

Earlier quoted context omitted.

Any ideas of supporting Mercurial, too?

For Mercurial check out RhodeCode which is also supporting some of unique Mercurial features like largefiles, phases, bookmarks.

Just to give you guys some credit: I've had the pleasure of working with RhodeCode on my previous job 2.5 years ago and it was an awesome experience. HG & Git support, full-text search, repo-specific access control, a nice gui, easy setup, etc. Unfortunately, most devs and sysadmins I talk to don't even know about your product, which is a real pity, as they all use the same inferior products and don't know what they are missing out on. Now i'm stuck with gitlab and bitbucket-server, which everyone thinks are great, but every time I log into them I silently cry out for rhodecode. Hope you guys are doing well.

Re: Moving to GitLab: Yes, it's worth it

#160

Post by dijit » Fri, Aug 05, 2016, 2:42 PM UTC

I posted before[0] about why I moved to gitlab; I'm using a self-hosted instance and the only real complaint I have is resource consumption. But if you bite the bullet a bit it's a really great product.

The other thing would be "ease of deployment" or lack thereof- if you're going for anything other than omnibus installs or docker images then it can be a bit painful. (I wanted to run on freebsd for example).

But, yes, it's super nice to have something not only comparable to github but even superior in some areas. I would definitely run the enterprise edition if that were my decision at work.

[0]: https://libsecure.so/t/github-alternative-aka-weve-moved-git...