371–380 of 408 posts
Earlier quoted context omitted.
But you don't force push with Gerrit? Just update your change set, then push to refs/for/ again.
It's effectively similar to a force-push.
Earlier quoted context omitted.
But you don't force push with Gerrit? Just update your change set, then push to refs/for/ again.
It's been a while since I used it, but I guess the more important point is that it's a rebase-based workflow. My memory was you had to force push your working branch to refs/for. Thank you for the correction. I've actually setup and run instances of it as two companies, but as I say, it's been a while.
I felt I needed to correct you because with Gerrit you reserve the concept of force pushing for exceptional cases, which I think is the correct mental model. Force pushing should not be done frivolously.
Earlier quoted context omitted.
What features do you think Gitlab lacks compared to GitHub? I haven't used the CI/CD features of either, but PR/MR features seem comparable. Is it the advanced workflow stuff and CI/CD integration where GitHub is better? Bots? I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. But I would be a lot mo…
> I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. A few paragraphs I recently wrote elsewhere: The entire state of code forges as a general thing in 2020 is all the evidence you could possibly want that version control systems (Git, I'm talking about Git) are themselves massively deficient in desi…
Interesting idea. You think we could develop a unified data model that covers source code, static files, documentation, project management and community management as a single unified thing?
That’s certainly ambitious, and I’d love to see it. For the moment it seem that Git has won for source code (in a pretty crowded field) because just that part was hard and it was a big improvement. The collaboration tools it includes, mostly around email, appear to be inadequate for most projects. So now we see a healthy ecosystem that adds rich collaboration on top of / next to Git.
> no widely used DVCS is actually distributed in practice
I think this is due to economic and social factors rather than technical ones. Fully distributing a Git repo is very doable, but harder to think about than the Github model. Plus you have all the normal P2P problems around who’s online and how good their connection is.
> tooling around version control is subject to platform monopolization
Again, I think this is simply the social network effect more than anything else. Making a website for your project let’s people find it, use it, and contribute to it. The bar to entry is lowered further if it’s a common platform, where people already have accounts and know how it works, and where they can get a consolidated view of all their activity.
Centralized hosting makes even more sense as projects grow and you only want a subset of the code on any given development machine. Eventually big monorepos preset serious scaling challenges.
Still... I completely agree that it would be awesome to have a more self-sovereign computing architecture writ large. I’m just pessimistic we can get there from here.
Earlier quoted context omitted.
Hi! I'm the PM at GitLab who works on Snippets, so thanks for providing this feedback. We do have Recaptcha support which can be configured - are you seeing these kinds of issues with that enabled/configured? One item that is on the roadmap that is coming and may be of interest is `Optional Admin Approval for local user sign up` - https://gitlab.com/groups/gitlab-org/-/epics/4491 . I'm not in the group working on tha…
Hi phikai, I built a privacy friendly alternative to ReCaptcha called FriendlyCaptcha [1], is there a possibility to see this integrated as a more user friendly alternative? Happy to chat (e-mail in profile) [1] https://friendlycaptcha.com/
Earlier quoted context omitted.
I immediately back out whenever encounter Recaptcha. The other day I was forced to endure it, because I wanted to delete my ancient Minecraft account, since Microsoft pulled a Facebook and are going to require a Microsoft account to play going forwards. Without exaggeration, it took me 15 minutes of training Google surveillance AI (had to solve it three times), for Recaptcha to let me in. I guess Google really hates…
You're doing something very wrong if you take 15 minutes to solve these and aren't on Tor. Even on public VPN and Firefox this doesn't happen usually. I know people that pick the wrong options to fuck with their models though, and then go on HN to complain about recaptcha being annoying.
Anyone thinking of moving to their own Gitlab instance with Gitlab CE-- either stay on Github or prepare to waste your time dealing with user spam bots that pollute your site's search results. In other words-- if you want the common use case for a FOSS project: 1. publicly viewable main repository with publicly viewable issue tracker 2. requirement to log in to view all snippets, user profiles, perhaps even other rep…
Hi! I'm the PM at GitLab who works on Snippets, so thanks for providing this feedback. We do have Recaptcha support which can be configured - are you seeing these kinds of issues with that enabled/configured? One item that is on the roadmap that is coming and may be of interest is `Optional Admin Approval for local user sign up` - https://gitlab.com/groups/gitlab-org/-/epics/4491 . I'm not in the group working on tha…
We can't use ReCAPTCHA or Akismet for obvious privacy reasons. The new "admin approval" process in 13.5 is interesting, but doesn't work so well for us, because it's hard to judge if an account should be allowed or not.
As a workaround, we implemented a "lobby": a simple Django app that sits in front of gitlab to moderate admissions.
https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/
The idea is people have to provide a reason (free form text field) to justify their account. We'd also like people to be able to file bugs from there directly, in one shot.
We're also thinking of enabling the service desk to have that lower bar for entry, but we're worried about abuse there as well.
Having alternatives to ReCAPTCHA would be quite useful for us as well.
Earlier quoted context omitted.
Are you sure you are human?
I'm human enough, and I've been a licensed driver long enough, to recognize that rumble strips at the side of a road are not crosswalks. But apparently enough bots thought they were that the system is now trained on that 'fact', and I as a human am forced to misidentify rumble strips as crosswalks to pass as human. It's bizarre.
Anyone thinking of moving to their own Gitlab instance with Gitlab CE-- either stay on Github or prepare to waste your time dealing with user spam bots that pollute your site's search results. In other words-- if you want the common use case for a FOSS project: 1. publicly viewable main repository with publicly viewable issue tracker 2. requirement to log in to view all snippets, user profiles, perhaps even other rep…
If you can, place your Gitlab CE instance behind an LDAP server. Have another site handle signups. (admitedly, setting up something with LDAP is often a massive pain. I duct-tape around it by using LdapJS on top of a CMS) I've had a handful of projects where human spammers will bother to create an account and jump through the loops, but in the 2-3 years of running a Gitlab instance, which has 1300 users, I only had 2…
Fundamentally, the Gerrit changes model is superior than the pull-request model. I also really like how Gerrit stores all its information in git repos, comments, settings and everything else.
The issue is everything that surrounds it. Talking from somebody who maintains an instance for a customer. The UI has all sorts of UX problems and takes a while to get into. The notification system is super noisy by default, we had to build a system on top and it's still not as good as GitHub's (which is also bad in its own respect).
Earlier quoted context omitted.
I'm not familiar with any UI bugs of any kind, but we don't use the "live editing" feature, maybe that's where you had problems. The big issue with Gerrit is on the "getting plugins to work" side of things, as they are kind of ad-hoc and almost totally undocumented, as well as the access model is too complicated but once that's all working, there is no need to deal with it. nitpicky culture, we maybe have that proble…
Wikimedia was using a super old version of gerrit for a long time. They upgraded recently (although the upgrade happened at roughly the same time as i left my job and took a step back from wikimedia so i dont have much experience with the new version). I think Wikimedia struggles a lot with code review culture in general. Different people have conflicting ideas about what good code looks like. It used to be very nitp…