You know, if they used the PR workflow with a CI that enforced standardised commit messages, this could be quite easily solved? Forcing everything through a mailing list seems to create more work for maintainers...
this post was submitted on 08 Oct 2024
191 points (91.7% liked)
Programming
17207 readers
306 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
Upd
Fix
Upd
Fuck
Updated file1
Fuck
Fix
Updated file2
Merge remote-tracking branch other-user1-feature
Fix after merge
Upd
Revert "Merge remote-tracking branch other-user1-feature"
Revert "Revert "Merge remote-tracking branch other-user1-feature""
You head him boys! Users of passive voice should be puched in the face!
Hey, I was wondering if you can update your commit with a punch in the face, if possible? No pressure thanks for contributing!
Updates & fixes -> I personally made updates with my bare hands and then also actively fixed some broken things also with my bare hands
Linus Torvalds expressed frustration over the use of passive voice in merge commit messages, preferring active and imperative language instead.
Things To Care About, vol 147, 2nd edition
Real developer's commit messages are all “Oops”.
Real developers'* commit messages
Oh I read it as the singular, as in "a real developer's ___"
maybe this will work
...
...
...
linting and unit tests
I like good commit messages that use less words but still give the full picture. If something hacky was done then a comment is better. I like mine with imperative voice since it avoids writing a prose.
"Fix a bug where when doing x then y happens"
"Add setting to control x"
Knowing you fixed a bug is minimal information and usually covered by an issue reference in professional software development. I'd prefer to see the commit describing what the fix is actually doing to fix the bug.
Right until the reference breaks. Ask me how I know.
I really don’t like starting with “fix.” You can just describe it without saying “fix” most times.
- Fix
Strings containing whitespace - Escape
Strings containing whitespace inCSVExporter
I always thought of the "how" being better explained by the code itself where you can see string.replace(" ", "\ ") as the actual fix while the message says the "why".
I would still have "Fix a bug where strings containing whitespace break CSVExporter" as my go to message.
I guess our viewpoints are different based whether we want the commit messages to represent tasks or changes. They both have their uses of course. Looking at changes to a file to know what people have done to it is better with a "changes" type message but looking at the history to check "did we actually complete this or was it just marked as completed in the issue tracker?" is better with a task based message.
Task management where every issue is put on a ticket and tracked would my type of messages obsolete but at my current company theyre very useful.
I basically stole your comment but made a worse version. On this note, though, there's sometimes value in using words like "fix" or other kinds of tagging or consistent formatting in the sense that you can do a meta-analysis of the repo history to look at trends (like the ratio of fixes to feature work) over time.
Issue tracking software obviates that, somewhat, but having that info embedded in the repo history lets you go further and look at which files have the most fixes etc.
Existing tools out there sometimes do this exact thing, but it can be manually done as well
Love a good commit message. I wish I could say what we perceive as “good” is instead thought to be “normal”, but we aren’t there yet I guess.
If the word “imperative mood” is hard to grasp, this is what I do. I just finish this sentence in less than 50 - 75 words, length depending on consensus.
This commit will …
Add more details in the body if needed.
This sort of style extends to PRs/MRs as well.
This PR/MR will …
That's actually helpful, thanks
When I do commit, I write up the title of what I did, and describe it, and then use periods for related commits. Just easier.
depending on the time of day my commits range from war and peace to 'jfc here is just the message "yeah" for the next twenty commits because the client keeps requesting stupid ass decisions".
As the day goes on
fixup=fixup -fuck
fuck
bleh
some bug squashin
implement stuff
Fixes configuration issues, and improves the UI for setting it up
And here it is in the kernel contribution documentation.
Simple example:
- bad: ~~Added foo interface.~~
- good: Add foo interface.
So the commit says what applying the patch will do, not what you worked on.
This has been the recommendation and the way to do it for decades everywhere I've been too.
good: Add foo interface.
Another commit style is summarizing what a commit does. In this case it would be someting like:
Adds foo interface.
I think this style is more in line with auditing code.
This indicative mood is something I would send back for correction or correct myself where I am the maintainer. However I understand that although this is pretty consistent through FOSS, it is not a settled matter especially in corpo-land. Most important is that it is consistent within a project. See many differing views here on Stackoverflow, noting the most popular answer though is imperative as Linus requests.
Honestly I've never thought about it this much. I'll have to make an effort to stop writing in past tense.
There are much smaller projects that ask for more from commits/merge messages. This is a normal ask
view more: next ›