this post was submitted on 11 Sep 2026
981 points (98.6% liked)

Programmer Humor

33359 readers
873 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 3 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] Pika@sh.itjust.works 13 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

is it auto reject, or just doesn't auto approve and leaves it open for manual review

It seems weird that you can't do a pr at all with 1000 line changes, any moderate size feature addition could hit that mark

[–] theolodis@feddit.org 6 points 2 weeks ago (1 children)

You know, you could just chunk it up in a way to keep it readable.

[–] Pika@sh.itjust.works 9 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

for a new feature request? a PR isn't a commit, it's a set of commits which would add to the line change amount.

Like even if you spread it out across 20 or 30 commits that's still going to be the same line count.

I guess you could push not yet functional or used code to lessen the line count change, but that seems in bad taste. I've always gone off the working repo should always be in build or clean state and a push or commit shouldn't break that.

[–] theolodis@feddit.org 5 points 2 weeks ago* (last edited 2 weeks ago)

I work in a Scrum team and we implement features iteratively, so we start with the minimal feature, merge it, get feedback, and go on from there.

At work there's no excuse to keep a feature in a stale branch until you accumulate 1000 lines of code change.

[–] kuhli@lemmy.dbzer0.com 3 points 2 weeks ago

Yeah, 1k is kinda a small limit but I get the logic, you can almost always break changes into smaller increments and not mass merge a mega PR that's hard to review