131–140 of 160 posts
I agree with the author so much. Every git forge looks like Temu Github. It's boring and lame.
At the top of this year I mocked up a hypothetical forge I'd use[1]. I then found the domain eol.sh was available so I snagged it. I'm currently using cgit for my personal public repos but I cannot wait to work on EOL. I'm gonna steal OP's ideas too, they sound good.
---
> PR approval is too boolean. The PR is approved or it's not approved. Real code review, like real life, lives in the middle This is have-your-cake-and-eat-it. PR approval is a permission so is a boolean. Of course it is. Either the code can be merged or it can't. What's being described really here is just something to make you feel slightly better about yourself whilst approving code you hate ("we should revisit thi…
Gerrit has -2...+2. -2: This is a bad idea, don't do that -1: This is a good idea but needs improvement +1: LGTM but I don't have enough knowledge or authority to approve +2: Approved
But with this, a non-maintainer could review be allowed to give a +1 or -1, but not a -2 or +2, and it is more clear that a "+1" isn't sufficient for actually merging the PR.
> PR approval is too boolean. The PR is approved or it's not approved. Real code review, like real life, lives in the middle This is have-your-cake-and-eat-it. PR approval is a permission so is a boolean. Of course it is. Either the code can be merged or it can't. What's being described really here is just something to make you feel slightly better about yourself whilst approving code you hate ("we should revisit thi…
> Either the code can be merged or it can't. Not an intuitionist, I see.
I think there's a gap in the market for a much simpler type of git service. All I need is a remote host to which I can push projects for others to see. I don't particularly want pull requests, actions or anything like that. Maybe a way of facilitating "releases" with compiled binary assets (built locally and uploaded). Forks can be handled by people cloning the repository and uploading a new project.
If gitlab makes even some of its current premium features free (mostly around push rules, and merge dequest guardrails), most comoanies will host their own gitlab in a heartbeat.
As someone that hasn't touched Gitlab in a long time, what are some examples of their merge request guardrails?
Earlier quoted context omitted.
This, seriously. The backend could be git on an SSH server, but if you have a slick design and 100% operational uptime-- you'll capture 80% of the developers using Github currently.
I think that's incredibly optimistic to the point of unrealism. Github, outages and all, is a known commodity with a reputation they can make money off of. Any replacement would have to offer not just compelling feature improvements and uptime, but to have a history long enough to make it trustworthy to migrate to. And uptime? Easy when you have a small number of customers. Much, much more difficult at a million+ cus…
> 1. Stuff happens in the wrong order. […] You don't want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push. My approach is to utilize https://pre-commit.com/ to have all checks available to run locally during commit (or push), but leave it to contributors whether they want to run it…
That works fine for some things, but it doesn't work for building and testing on other platforms. For example, if I am running on linux, pre-commit won't be able to check that my changes also work on Mac and Windows.
Earlier quoted context omitted.
> you can just run the tests on the local machine, and you should be running them as part of your workflow. aren't you describing why you'd want a pre-commit for this? you do not have to remember to do so, and new people do not need to learn it.
There are different workflows. I sometimes commit code that does not compile, so that I have a checkpoint. Or because it’s 16:59 and I want to leave the office (and I want to protect the code I wrote from hardware failure). I’d be annoyed if any pre-commit checks took more than 2-3 minutes, and for most projects, that is not enough to build and run any meaningful tests (especially remotely).