291–300 of 408 posts
Earlier quoted context omitted.
The repository storage size is 10GB [1]. I wouldn't consider that "extremely small". [1]: https://docs.gitlab.com/ee/user/gitlab_com/index.html#accoun...
That's for container registry, packages, code, artifacts, everything. I have a single project in my monorepo that produces a 512MB binary file and stores it as an asset. In 20 CI runs, assuming there was 0 code in repo or anywhere else, we'd use up the entire budget. We make more than 20 commits/day.
Earlier quoted context omitted.
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/
> up to 20 seconds on old smartphones That sounds like a very battery-unfriendly idea.
The alternative: loading a third party script and multiple images (~2MB) to label for ReCAPTCHA and spending time performing the task also takes some battery (and mental) power.
Earlier quoted context omitted.
But you don't force push with Gerrit? Just update your change set, then push to refs/for/ again.
It is a force push under the hood. You’re removing an old commit and creating a new one.
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…
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-3 incidents (we keep an eye on recent projects, snippets, etc).
Earlier quoted context omitted.
What advantages do you see in Gerrit? Do they require a lot of experience in order to be realized?
I much prefer the model of force-pushing your development branch to create change sets. It lets you more easily see how development evolves in response to feedback. And the final state of the branch which gets merged leaves all the in-progress work that no one cares about behind only in Gerrit. With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. A…
I'm not sure about Gitlab, but Github has recently added a feature where you can view the diff between the old branch head and new one. But, as far as I'm aware, there's no way to check out the previous branch head from the repo due to a lack of a remote branch pointing to it.
At least git itself provides a range-diff command that allows you do see a diff between the commits between two versions of a given branch.
Earlier quoted context omitted.
I am yet to know people who Review code and use Gerrit to name a better solution. I belonged to a team that used Gerrit for Review and Hosting, we changed to hosted Gitlab because people missed a "GitHub-like UI" they were used to. It was unanimous that Code Review on Gerrit was way better: 1. You start reviewing the commit message, that is the first touch point with a change everyone has 2. Navigation is done from f…
> I am yet to know people who Review code and use Gerrit to name a better solution. What about reviews via patches sent to a mailing list? I haven't looked into Gerrit for a while, so one question I have is how it handles related commits? The mailing list approach can group them in a single thread tied by a cover letter message where each commit along with the associated diff from the parent working tree is a message…
Earlier quoted context omitted.
It is a force push under the hood. You’re removing an old commit and creating a new one.
It's not a force push under the hood. Under the hood a new branch is created (first patch set is /refs/changes/nnnn/0, second is /refs/changes/nnnn/1, etc.). From the end user perspective the result is quite plausibly similar to force push.
So what happens when you push to changes/nnnn/12 when revision 11 hasn’t been created?
Earlier quoted context omitted.
> I am yet to know people who Review code and use Gerrit to name a better solution. What about reviews via patches sent to a mailing list? I haven't looked into Gerrit for a while, so one question I have is how it handles related commits? The mailing list approach can group them in a single thread tied by a cover letter message where each commit along with the associated diff from the parent working tree is a message…
To be polite, I think the target audience of these tools might not include you. While that workflow works for you and, apparently, scales for some very large projects like the Linux kernel, it isn't a good solution for an enormous number of people which is why tools like Github, Gerrit, GitLab, and others exist.
Insinuating that I'm a special case doesn't add to the discussion.