If your commit messages are more than one line - straight to jail.
Details are for PR descriptions or tickets.
Exactly this. OP has no idea what they are talking about
Disagree. Write notes in commits if it makes sense. Tickets and MRs are more important, but there’s no reason you can’t also have detailed commits.
If you do have 1000 lines changed (and it’s not just adding test data or something), then that is a sin. A sin of not splitting commits.
Write notes in the commit description if you're so inclined, don't write an essay in the commit message. Context belongs in the PR description and/or the ticket
My comment was tongue in cheek, sure you can have a bit more detail I don't care, especially if you're just working on a pet project and not actually tracking anything outside the repo.
In the workflow of most dev teams though, commit messages are really only useful as place markers in the history and anything you put in them is effectively useless once they fall out of the blame or realistic time window to revert to that commit. If that detail is important it should be recorded somewhere else - or just say "fuck it read the code".
God forbid you have user facing release notes autogenerated from commit messages and you put a wall of text about some hacked workaround you implement.
first line of commit: succinct summary like the subject of an email
<blank line>
entirety of Moby Dick
there are two valid commit messages: "fixed issues reported in <ticket link>" and "did a bunch of work that's not going to be approved because there's not ticket"
git commit -m "fixed bugs and added things"
I have never written more than one line in any commit message.
Is this better or worse than 1000 line commit messages for 1 line changes?
“fx”
"updated composer.lock"
Because our company is an example of "how not to do things" I might have only changed one line, but after running the generators there will be thousands (I think the worst ratio was 1 manual line to 10000 generated) so what am I supposed to put there?
Before you ask, no I can't skip it or it will fail at compilation and I also can't modify the build chain to auto generate those during compilation as it would take 15+ meetings and 3 months.
My favorite was keeping the file creation date as a text in the file (which gets updated even if the contents of the files weren't changed), we are running GIT, we can check when that file was last modified.
happens when u r a solo dev
git commit -m "fix: fix various issue"
30% of mine are "rm", "mv", "types", "linter"
something feels fishy about this comic’s origins
This seems normal to me because we reference the issue # & resolution reference from gitlab in commits.
I’m just doing the date + fixes
OP thinks books title should get longer as the book gets larger.
Hello and thank you for posting to r/programmerhumor! You have previously posted two submissions within the past 24 hours so this submission has been removed. If you intend to repost it later we recommend deleting this one first to prevent other bots from removing it as a duplicate.
BOOP! BLEEP! I am a bot. Concerns? Message /r/programmerhumor. Previous post(s): 1lvsioo, 1lw7hb2 | limit: 2 per 1d | next eligibility: 2025-07-10 19:53 UTC
I dont understand why "plop" isnt a good commit msg. Read the code to see the chnages. Its written there
Edit : i forgot reddit people are lost and DV if they don't see the /s
Literally me.
-3500,+4500
"<TICKET NUMBER>"
my coworkers dont want to review my code, so why should I care.
Maybe because your changing thousands of lines at a time
I would hate to work with you. You could possibly be the sole reason i quit that job.
git commit -m "changes"
“chnages” in most cases
git commit -m "things and stuff"
is mygoto
I used to that, but with the word "update"
"did the needful"
“Misc fixes”