yuh-source / yuhs-chill-macro

DGAF AV macro type shi
GNU General Public License v3.0
2 stars 0 forks source link

commit messages are not in the proper grammatical form #1

Open nosewad opened 1 week ago

nosewad commented 1 week ago

Ah, the humble git commit message—a window into the soul of a project! But, folks, we seem to have stumbled into a temporal rift. Our commit messages are stuck in the past, quite literally. Instead of boldly declaring "Fix typo" or "Add feature", we’re over here reminiscing with "Fixed typo" and "Added feature". While this isn't exactly the end of the world (or the repo), it does throw off the proper flow of git history.

You see, git logs are meant to read like a to-do list for your code, not a diary entry. Commands like git revert or git cherry-pick work better when messages describe what the commit does, not what you already did. It’s the difference between saying, "Bake cookies" and "Baked cookies"—one gets the job done; the other makes me wish I had cookies.

So, let’s show some love to the imperative voice. Treat your commits like you're bossing your code around: "Fix bug," "Add tests," "Delete unnecessary file." Because if your code can’t follow orders, who will? Let's rewrite the past (tense) and future-proof our git history. 🚀

🤓 🤓 ☝️

but i'm just a chill guy.

yuh-source commented 1 week ago

While I appreciate the passion for clarity and structure in git commit messages, I think there’s room for a bit of nuance here. Yes, it’s important for commit messages to be concise and informative, but I’d argue that the “past tense” vs. “imperative tense” debate might be missing the forest for the trees.

First off, the idea that git logs should read like a to-do list is, in theory, solid. But the reality of software development is that commits represent changes in the project at a particular point in time. Sometimes, past tense is a more accurate reflection of the process—you did something (fixed a typo, added a feature), and now it’s part of the project’s history. The idea that "Fixed typo" is somehow confusing or less effective than "Fix typo" might be a bit of a stretch. Both are clear, and both describe the same outcome. In fact, there are plenty of developers who find past tense to be more natural and readable when looking back through the commit history.

Second, while using the imperative voice can be a great guideline, it’s not always a hard-and-fast rule. Commit messages aren’t commands for the code to obey—they’re an explanation of changes made, which often involves a narrative of what happened. "Added feature" may be more suitable when you want to indicate a completed action that’s part of the project’s evolution. It’s less about telling the code what to do and more about explaining what was done.

And let’s not forget, the way we write commit messages is also subjective. What’s essential is consistency within a team. Some teams might prefer imperative, others past tense—it’s the shared convention that matters more than the tense. So let’s ease up on the strict rules and let people write in the style that makes the most sense for them.

In the end, if a commit message tells me what was changed and why, I’m happy—whether it’s "Fix bug" or "Fixed bug". Because, honestly, as long as I’ve got those cookies, I’m good either way. 🍪/s