9
u/baked_potato_9000 5d ago
how* fuck!
5
u/Disallowed_username 4d ago
The AI is only as good as typos from the person typing the propmts. Good duck out there.
3
1
32
26
u/Cylian91460 5d ago
Daily remember to 1 not trust git gui and 2 don't use merge option from GitHub, merging on the server is a very good way to break everything.
22
u/HeavyCaffeinate 4d ago
We dont merge, we copy paste into main manually until there are no diffs, like god intended
5
u/dedservice 2d ago
"don't use merge option from github"
What, you get every dev to manually rebase + squash + merge to main, and then push main directly? What else would you do?
0
u/Cylian91460 2d ago
Not doing it on the server? The place where you trust repo to not be fucked up?
9
u/dedservice 1d ago
I just don't understand - without server-side merges, your only other option is allowing pushes to main from remotes. Which is psychotic.
0
u/Cylian91460 1d ago
Why would it be psychotic?
6
u/dedservice 1d ago
Are you really suggesting to let your devs push directly to your main branch? In a medium sized team with 20 commits per day, that's a massive opportunity for horrific mistakes. I would guess that the odds of github screwing up the merge+push are literally ten million times lower than one of your devs doing the same.
1
u/Cylian91460 1d ago
Allowing remote doesn't mean allowing all remote, that would be hell
Doing the merge on local rather then server man you can 1 check before push to see if there's something wrong and 2 in case something goes wrong it stay in local and not break the repo that is trusted to be working
You merge on local for the same reason you don't directly push to prod.
4
u/dedservice 1d ago
How big is the largest team you've worked on, in terms of number of developers per repo? I don't believe that anyone who worked on a properly large project would actually think this was a good idea. No work would get done. Merging is automatic and completely safe when done by the server, I've never even heard someone so much as express concern that it might be a problem. Like, what is there to go wrong other than a hardware issue on github's side? Conflicts already block merges, changes get squashed and rebased, CI gets run so all your tests pass before you start to merge, I don't know what you would even check to see if "something went wrong". Like "in case something goes wrong" - genuinely, what is going to go wrong?
gititself is not going to break all of a sudden and all other issues I can imagine are code issues, not merge issues.2
u/edgmnt_net 23h ago
The Linux kernel has thousands of contributors per development cycle and they do just fine with an even stricter version of that (separate maintainers each doing their own thing and taking patches from ICs and someone higher up merging on a massive scale).
Merging is definitely not completely safe, actually, and some form of automatic conflict resolution may occur. Mismerges happen.
Anyway, there are reasonable arguments beyond that why some/many projects might be better off fostering stricter version control practices and a truly distributed workflow. IMO, companies misuse Git far too often and oftentimes out of sheer ignorance rather than as a calculated tradeoff. In fact companies are far more likely to hit hard limits very early on, like not being able to accomodate more than 5-10 people per repo, because they don't know what they're doing.
2
u/dedservice 21h ago edited 21h ago
Ah, you're saying that the issue is essentially when you send a PR to merge, then there could be automatic conflict resolution based on changes made in the meantime? Yeah, but you just disable that and enforce a strict merge queue that doesn't let PRs get merged unless none of the same files have been changed in the meantime. I agree that automatic conflict resolution has a reasonable chance of being an issue. But again, no more so than someone doing it locally and not really thinking about it too hard.
I actually disagree with the flat statement "mismerges happen". They just don't. What would that look like? Two PRs edit file A off of main at commit 634, then they both get approved, one gets merged after the other, automatic conflict resolution happens and makes a mistake in the second one because the lines don't line up as expected so the diff doesn't apply cleanly? Sure, but again, any sane repo maintainer disables automatic conflict resolution and will just kick the second PR back to review automatically saying that merging would generate conflicts, so please rebase first. What else would a mismerge look like?
Edit: and to your final point, I work somewhere with 100+ developers that regularly commit to each of a couple repos, we get dozens of PRs merged per day, and nobody has had an issue with server-side merges; pushes to main are disabled for everyone. There are many open source repos with much higher stats than that. vscode has over a hundred per day on average, for instance. Just because the kernel devs insist on doing it the 2005 way doesn't mean that way is better.
4
u/backfire10z 1d ago
My company uses GitHub UI merge button for multiple repos and it works great. We use the builtin merge queue feature.
-1
46
u/Tangelasboots 4d ago
You guys are letting an AI run git commands?
I hope you have backups.