ProgrammerHumor
commitMessagesAreForNerds
Discussion
Plot Twist: The AI made the changes and they were committed without review and the production broke and the server overloaded leading to collapse of civilization. The End
Ahh yes, matrix ahh moment
this is why I always add copilot as a reviewer to all my pull requests
I have one on one in one of my repos where I couldn't remember the last time I'd pushed a commit so the message just said "I have no idea what's changed since the last commit. Just pushing now so I have something to roll back to". It was 2200 insertions and 700 deletions.
How do you live like this
He fixed the max-line-width!
That's just somebody who pulled an all-nighter and didn't realize he's been working at this for the past 16 hours. Normal programmer behaviour.
When I shave seen this, it's because they tried to do a pull request to the wrong branch and stupidly did not double-check the changes. That is, being in a rush leads to mistakes.
You commit every day?
Several all-nighters?
I love this cat
10,000 small fixes
black *.py
I was thinking pipenv lock
Maybe he just reformatted
“Changed all tabs to superior quadruple space indents. You’re welcome.”
Hopefully they just removed trailing white space and other lint.
When your codebase is millions of lines this could be considered small
I get what you mean, but a simple "generate commit message" is much better than " small fixes"
I was kidding btw lol sorry forgot /s
/uj No worries mate, all good
/rj whyVibeCodeWhenYouCanVibeCommit
Only 2558 lines really
In Delphi, lines are limited to 255 characters.
Plot twist: the regular commits are much larger
Regular case. It could be variables renaming or light refactoring of components, services and peripheral features.
That small fix better be changing a formatter rule
Or changing import javax.inject.Inject; to import jakarta.inject.Inject; and auto-cleaning imports.
I accidentally did this with Perforce, I checked out all files and was like damn that is a big changelist until I noticed
I saw this some times with a dev that really never understood the new style of git, or how the web based pull request software worked (nasty azure devops). He'd honestly think that he only changed 1 line but then there's but thousands of changes because he'd be merging to a wrong branch and he never noticed, and never looked at the pull request to double check the changes, etc. Ie, trying to do it quick and dirty and ending up with a huge mess.
Measure twice, cut once. This adage applies with software too, it means go slow and be careful.
"tabs to spaces"
Accidentally committed a new package-lock.json
See, this happens to me all the time, but mostly because I keep using CSVs with a few thousand rows of data as my test files. Update a couple of those and yeah, it'll look like this quickly.
Everyone gangsta till the PR doesn't say how many lines were modified, but instead goes to "infinite files were changed"
I did something like this once. But I just replaced text files used in unit tests, and they had a lot of lines. The code change was just the file name.
Somebody used the wrong base branch 😅
LGTM
That's just a package.lock file in a medium sized Angular app.
Plot twist, it's just switching from 3 spaces indentation to 4.
New prettier config.
"Updates" or "." are my favourites
And then seeing 99% of the changes are "Re-formatting" of code.
Yes so much this, and then they don't explain anything in the pr and git can't hide the whitespace because everything moved slightly and one line in the middle was changed.
Then after half an hour of reading over it you realise they actually changed ONE line in the whole thing and the bug report was just ai fluff around the fact that a button was misspelled and the api was unreachable because someone trimmed an extra slash out.
Bonus if this person surprised you with a 500 line pr after dozens of 10 liners!
Minor refactoring
Generally, this sort of stuff I squeeze in to actual tickets. We can't "fix" code without there being an official ticket being opened, which is necessary for tracking purposes, and to prevent this sort of shenanigans(*). And then nobody wants to create a ticket for something this minor, which will waste the time of so many people.
Now certainly, if so much stuff piles up that it's major refactoring then that can be useful to make a ticket for it. At the very least it forces other team members to look at it: if you were a genius in this redesign then the others will benefit by learning from your genius; if you were an idiot then they'll notice and suggest you abandon the changes.
(*) That is, someone just wants to sneak in a quicky fix, the boss doesn't need to know, the testers don't need to know, nobody needs to know and it'll just be a secret - until it crashes badly at a customer site :-) I see a lot of this in some repos from way back in the wild west startup days when there were no rules or even code reviews.
"various bug fixes" also my thing
Subject, verb, predicate. Is "bug" the verb? I have dinged team members in the past for not using full sentences, and sometimes they give a blank look that says "we're not a team, we're an autonomous collective..."
A predicate INCLUDES the verb, no need (and in fact makes it more confusing) to list them like that. You're mixing two types of classifying words. Noun, Adjective, Verb (just the big ones) is for defining words independently from one another and Subject, predicate, etc is for defining how words are USED in a sentence.
Also commit messages don't ALWAYS need to be full sentences.
Edit: also, also, commit messages are usually written in the imperative, that being the case "fix the bug" is technically a full sentence despite not having a subject (bug is the object, not subject). The subject is whoever the imperative sentence is directed toward.
I don’t know about all your fancy words, sir; but I prefer “Fixes various bugs” over “Various bug fixes” any day of the week.
You are technically correct, the best kind of correct.
And where exactly are the managers and team leads that let this through?
These messages are important in the long run, because someone's going to be looking at the history someday to figure out why a certain change was made. As in, I want to remove the code as it seems useless, but let me see why it was added just in case there's a reason I am overlooking.
Huh, wait till you find out that you, yourself wrote it 3 years ago and didn’t leave any clues as to why.
That has indeed happened to me. Especially embarrassing as my thoughts at the time were "what kind of moron wrote this!"
“Why in gods name would I do that!?” 3 hours of debugging later… oh yeah, every line was there for a reason.
At least I leave explanations now so it doesn’t happen again in another 3 years.
I personally use "i am stupid"
-fix