Just a quick little video I made for fun :) Next video is on fixing merge conflicts, will be out next week (they take me about 20-30h to create so thanks for your patience). Please consider subscribing if you like this type of content! I'll also post more non-RUclips content on my website in the future, and I might try live streaming at some point. So if you'd like to get notified when that's released, please leave your email address there: philomatics.com/youtube
I read somewhere once that a commit message should complete the following sentence. "If you apply this commit it will ..." That made sense to me and I use it as a mental template for writing commits.
I prefer present tense because it gets rid of unnessary letters in the commit messages (mostly the letter d at the end of verbs), since Fix is shorter than Fixed, Create is shorter than Created, etc. But i do use a combination of keywords (docs, fix, feat, style, test, etc.) and present tense in my commits.
I would say that the reasons to use present tense in commit messages are - it's the convention (including stuff like autogenerated merge messages) - it's shorter and you want to fit in 80 characters because for some reason even modern tools can still crop things after 80 characters - even when it's mostly a work log, I think it makes more sense to use present tense the moment you start doing things like reverting commits, cherry picking between branches, etc. In git, commits effectively represent "changes you can make." Even if you mostly just have a flat history, I think it makes more sense with basically every other functionality of git.
0:44 yes... that's what the message is for. It's something relative to the commit, not about what the developer did or the project manager manager wants.
present tense makes more sense to me, even when you are using a project alone, or in a centralized core team, because you are telling the team what you are adding when they do a PR review.
Not only is present tense shorter, it is also for myself to apply my own commit as a patch, so it makes sense. If I use past tense my subsequent commands later look odd. Git rebase for example and merge will feel like you're wasting time fixing already done things but a merge and rebase can take significant effort and time
I personally use present tense because 1. It's common enough and 2. it's shorter. Everyone knows that a commit message describes what was done in that commit, so verb tenses are redundant. That said, I don't really care if my team uses past tense either. Something something hobgoblin of little minds.
Commits are like functions that manipulate the source code in order. And you wouldn't name functions in past tense. But I do like your loaded tactic of "either agree with me or toss a coin"!
I always used past tense in my commits, and also always used title case, but in my latest project I finally gave in and used present tense and all lowercase, because I was rejected by a lot of recruiters over this. I tried to convince them that I can write the commits in whichever style the team was using, and that I preferred to use past tense on my projects, but it fell on deaf ears. Many recruiters take this as a sign that someone is inexperienced and had never worked in a team.
Applying a coherent style of conventional commits and present tense is worthwhile if there are more than two developers involved, the team structure is likely to change, there is an influx of new people and so on. From time to time, someone will need to dig through git history and will be grateful. Normally, you will reference the issues in in your pms solution, which then will keep track of, what has been done to achieve what.
I'm bootcamping atm, and we have been instructed that the only acceptable way to write a commit is present tense, with prefixes. The prefixes I really like, and make sense. I really hate the present tense commits though, for some reason I find them much harder to write than past tense.
Thinking about commit as a patch. When applied, this commit will "fix the cancel button". It also makes much more sense to read imperative messages when cherry-picking.
Another argument for present tense is that all of these words are also nouns. The commit *is* a fix, or it *is* a refactor. like you mentioned feat, it wouldn't make sense to say this commit will "feat" or "feated" or whatever; rather, the commit itself is the feature. I think this makes more sense than seeing a commit as what applying it will do or a work log tbh but it's 3 sides of the same coin
I personally support using present tense. I think past tense is usually quite bad and I agree with the format/style advocated by the blog post "How to Write a Git Commit Message" by CBEAMS.
for me writing commit messages in past tense would sound like the commit is just a log message of what has been done when, but for me commits also apply the actual changes (i mean, which they do) so writing mine in present tense feels like it makes more sense, e.g. (This commit will...) "Fix this one feature not working correctly"
I think both would be better in my opinion i mean - past tense when the commit is picked or given to you from issues or maintainers - present tense when you are contributing on your own ( no taking from issue ) i think in this case we mostly would use past tense. since everyone always chooses from issues. Anyhow that's my comment.
Present tense is superior if not at least because in English it is usually the fewest characters. Saving an `ed` or `d` is helpful when you are so space constrained.
I used past tense when I first learned Git. I thought of it like a changelog. Soon enough I found most people used present tense, at first it read weird but I started thinking of it as 'what this commit will do to the existing codebase' or 'what must be done to the codebase'. It had the added benefit of saving me a few characters each commit. Next question, though: do the first words of commit messages even need to be capitalised?
"in this commit ... was fixed", "in this commit I fixed ..." In fact each commit represents a state of the repository (that's how git works), not a set of changes, so a commit would be a state with something done to it, not a patch/action.
You can read it even as "If you apply this commit it will ... fix or whatever". This and that is stupid. Everything is stupid. It's irrelevant. We stop here.
A pet peeve of mine is when people write bad commits, no matter the tense. They write for example "removed method from X class" or "added X and X property". This is not a good commit message. You should explain WHY you removed the method, why you added the properties, what was the purpose of the change. The change in itself, I can see by looking at the changes in the commit. Commit message should explain the purpose of the changes, not describe the changes themselves. Most of the time at least.
I disagree, commit message title should describe what was changed, so when I'm looking for change, I can easily find it by simple ctrl+f on git history or grep on git log. The reasoning is good in pull requests or as addon in commit body, but for sure not in title ;).
Fix can be imperative form of the verb "to fix". Ex: "fix error 232" Or "fix" can be a noun, like you say "Fixed" can be the past tense verbal form, as in "I fixed the bug", or it can also be an adjective, such as "the bug is fixed".
@@seanvogel8067 "Fix #32" is the 32nd fix, which means the "fix" is countable, which is a property of nouns. The word in the thumbnail is a noun. To interpret it as "[to] fix [error] #32" is a bit of a stretch. If we're dealing with nitpicks, this is a bigger problem than whether the phrase should be in present tense or future tense-since the plain reading of the message is that fix isn't even a verb at all!
@@wyrxr , you are more likely to be correct that "Fix #32" is a noun, and your logic is sound, but I wouldn't be dogmatic about it considering some of the English construction I see on the Internet*. But anyway, my bad. I didn't notice the context of the word "fix", or I would've understood. *Ex: how to undo a commit?
What if project decides to change it? If your project was closed source before, and then you decide to make it open source, do you need to change your message style?
...What's the gist of this video? Sure, a lot of things are more important than git commit messages, so let's all spam "minor fix", "refactor" commit messages then. It's not that important after all, right? Btw, me personally - present tense. They call it 'being a man of culture"
As long as you don't use "conventional commits", we can be friends. Present tense is correct, but it doesn't matter too much. Start polluting commit history with noisy prefixes and we'll start having problems.
Just a quick little video I made for fun :) Next video is on fixing merge conflicts, will be out next week (they take me about 20-30h to create so thanks for your patience). Please consider subscribing if you like this type of content!
I'll also post more non-RUclips content on my website in the future, and I might try live streaming at some point. So if you'd like to get notified when that's released, please leave your email address there: philomatics.com/youtube
just use “Bug fixes and other improvements” every time
gigachad brogrammers refuse to elaborate on why they do it
Sounds like most release notes on the app stores ;)
Bug fixes and performance optimization -every single system update on my phone
Just use "YAC" as for "Yet another commit", or if you're REALLY in hurry: "yac".
Nah, "111", "qwe" and "a" are better.
I read somewhere once that a commit message should complete the following sentence. "If you apply this commit it will ..." That made sense to me and I use it as a mental template for writing commits.
that's actually a pretty good hack, ty!
That's actually a pretty good hack, ty!
Yes it should. They should be written in the imperative mood ! 😊
Or you could just make the commit message, "if you apply this commit it will."
😬
future tense
You WILL accept this commit;
@@elzabethtatcher9570 😅
"perhaps..." commit
I use that along with some faith:
"I pray that this will fix the bug [#42069]"
I prefer present tense because it gets rid of unnessary letters in the commit messages (mostly the letter d at the end of verbs), since Fix is shorter than Fixed, Create is shorter than Created, etc. But i do use a combination of keywords (docs, fix, feat, style, test, etc.) and present tense in my commits.
"If we apply this commit, it will "
is much better than
"We merged this commit because it "
I would say that the reasons to use present tense in commit messages are
- it's the convention (including stuff like autogenerated merge messages)
- it's shorter and you want to fit in 80 characters because for some reason even modern tools can still crop things after 80 characters
- even when it's mostly a work log, I think it makes more sense to use present tense the moment you start doing things like reverting commits, cherry picking between branches, etc. In git, commits effectively represent "changes you can make." Even if you mostly just have a flat history, I think it makes more sense with basically every other functionality of git.
Nah, my commit messages will always be: "Dunno. I forgot to commit before and now I did too many changes to remeber all of them"
VSCode can find the changes you did but by the time I remember I've done 17 changes that will never fit into one commit message lol
git diff to see what you changed, then git add -p to stage part of a file for a commit
0:44 yes... that's what the message is for. It's something relative to the commit, not about what the developer did or the project manager manager wants.
present tense makes more sense to me, even when you are using a project alone, or in a centralized core team, because you are telling the team what you are adding when they do a PR review.
Not only is present tense shorter, it is also for myself to apply my own commit as a patch, so it makes sense. If I use past tense my subsequent commands later look odd. Git rebase for example and merge will feel like you're wasting time fixing already done things but a merge and rebase can take significant effort and time
I personally use present tense because 1. It's common enough and 2. it's shorter. Everyone knows that a commit message describes what was done in that commit, so verb tenses are redundant. That said, I don't really care if my team uses past tense either. Something something hobgoblin of little minds.
Commits are like functions that manipulate the source code in order. And you wouldn't name functions in past tense.
But I do like your loaded tactic of "either agree with me or toss a coin"!
I always used past tense in my commits, and also always used title case, but in my latest project I finally gave in and used present tense and all lowercase, because I was rejected by a lot of recruiters over this. I tried to convince them that I can write the commits in whichever style the team was using, and that I preferred to use past tense on my projects, but it fell on deaf ears. Many recruiters take this as a sign that someone is inexperienced and had never worked in a team.
Wow that's insane! I would never have thought that recruiters would reject you over this. thanks for sharing this!
This is one of the most dystopian comments I've ever read
@@VolcanicPenguin Oh, it gets a lot worse than this! 😅
Applying a coherent style of conventional commits and present tense is worthwhile if there are more than two developers involved, the team structure is likely to change, there is an influx of new people and so on. From time to time, someone will need to dig through git history and will be grateful. Normally, you will reference the issues in in your pms solution, which then will keep track of, what has been done to achieve what.
I always read/write commits in this context: “This commit will ”
Imagine how easy someone’s job as a developer must be that they start worrying about verb tenses in commit messages.
Hah, the dream, right? Maybe it was just some kind of distraction or morbid curiosity ;)
I'm bootcamping atm, and we have been instructed that the only acceptable way to write a commit is present tense, with prefixes. The prefixes I really like, and make sense. I really hate the present tense commits though, for some reason I find them much harder to write than past tense.
Thinking about commit as a patch. When applied, this commit will "fix the cancel button". It also makes much more sense to read imperative messages when cherry-picking.
@@streettrialsandstuff oh dang. That's a really helpful tip, thank you!
In some project I caught myself writing in present progressive. Like when I look at the changes a commit applies, it is happening right now 😅
Another argument for present tense is that all of these words are also nouns. The commit *is* a fix, or it *is* a refactor. like you mentioned feat, it wouldn't make sense to say this commit will "feat" or "feated" or whatever; rather, the commit itself is the feature. I think this makes more sense than seeing a commit as what applying it will do or a work log tbh but it's 3 sides of the same coin
I personally support using present tense. I think past tense is usually quite bad and I agree with the format/style advocated by the blog post "How to Write a Git Commit Message" by CBEAMS.
for me writing commit messages in past tense would sound like the commit is just a log message of what has been done when, but for me commits also apply the actual changes (i mean, which they do) so writing mine in present tense feels like it makes more sense, e.g. (This commit will...) "Fix this one feature not working correctly"
I think both would be better in my opinion i mean
- past tense when the commit is picked or given to you from issues or maintainers
- present tense when you are contributing on your own ( no taking from issue )
i think in this case we mostly would use past tense. since everyone always chooses from issues. Anyhow that's my comment.
I just smash my keyboard with random characters. I also randomly commit when I feel like it.
Present tense is superior if not at least because in English it is usually the fewest characters. Saving an `ed` or `d` is helpful when you are so space constrained.
I haven't been able to make up my mind on which I prefer, though I've been able to stick with one style per project (I hope)
my commits when from "add bla bla" "rem bla bla" to "small delta" and now all my commit messages are just "sm"
I used past tense when I first learned Git. I thought of it like a changelog. Soon enough I found most people used present tense, at first it read weird but I started thinking of it as 'what this commit will do to the existing codebase' or 'what must be done to the codebase'. It had the added benefit of saving me a few characters each commit.
Next question, though: do the first words of commit messages even need to be capitalised?
What tense is "[date] [time] last commit before I sleep"
TL;DR the facts that git recommend present tense and almost everybody uses should be sufficient to decide to always use present tense.
Cliff jumper.
"in this commit ... was fixed", "in this commit I fixed ..."
In fact each commit represents a state of the repository (that's how git works), not a set of changes, so a commit would be a state with something done to it, not a patch/action.
You can read it even as "If you apply this commit it will ... fix or whatever". This and that is stupid. Everything is stupid. It's irrelevant. We stop here.
@@ThisDaveAndThatJohn ok, future tense it is then
@@user-tk2jy8xr8b, lol
Ha! Had to laugh seeing Gilfoyle and Dinesh argue.
Let's see Paul Allen's commit messages.
Present tense for commits. Past tense for release notes.
Why focus on commit msg?
Just focus on building things.
I think I already know Git very well and I also teach it in our company. your videos are simple and understandable. Keep it up!
Love these videos on git.I am learning alot
Better yet - use meme phrases instead
Present tense is the best
Agreed. I don't even understand why there is an argument.
A pet peeve of mine is when people write bad commits, no matter the tense. They write for example "removed method from X class" or "added X and X property". This is not a good commit message. You should explain WHY you removed the method, why you added the properties, what was the purpose of the change. The change in itself, I can see by looking at the changes in the commit. Commit message should explain the purpose of the changes, not describe the changes themselves. Most of the time at least.
Agreed, writing good commit messages is actually quite difficult. maybe I should make a more serious video on this actually :)
I disagree, commit message title should describe what was changed, so when I'm looking for change, I can easily find it by simple ctrl+f on git history or grep on git log.
The reasoning is good in pull requests or as addon in commit body, but for sure not in title ;).
I always write git commit messages using past tense
I guess I'll be the one to say: The word in the thumbnail isn't a verb at all, but rather a noun. "Fix" is the correct option there.
Fix can be imperative form of the verb "to fix".
Ex: "fix error 232"
Or "fix" can be a noun, like you say
"Fixed" can be the past tense verbal form, as in "I fixed the bug", or it can also be an adjective, such as "the bug is fixed".
@@seanvogel8067 "Fix #32" is the 32nd fix, which means the "fix" is countable, which is a property of nouns. The word in the thumbnail is a noun. To interpret it as "[to] fix [error] #32" is a bit of a stretch. If we're dealing with nitpicks, this is a bigger problem than whether the phrase should be in present tense or future tense-since the plain reading of the message is that fix isn't even a verb at all!
@@wyrxr , you are more likely to be correct that "Fix #32" is a noun, and your logic is sound, but I wouldn't be dogmatic about it considering some of the English construction I see on the Internet*.
But anyway, my bad. I didn't notice the context of the word "fix", or I would've understood.
*Ex: how to undo a commit?
I use “maybe tense”
Are you planning to shoot training videos on the use of GitHub?
I might! Anything specific you'd like to learn more about?
I had same problem. I guess I still have
my repo my rules!
the commit: Added non addable fix it
Closed source = past tense
Open source = present tense
What if project decides to change it? If your project was closed source before, and then you decide to make it open source, do you need to change your message style?
@@kezzyhko Obviously replay all commits and modify the verb tense to the new style.
You are dope.
And I am envious.
simple and to the point, thank you :)
yeah, my convention is: I don't care
...What's the gist of this video? Sure, a lot of things are more important than git commit messages, so let's all spam "minor fix", "refactor" commit messages then. It's not that important after all, right? Btw, me personally - present tense. They call it 'being a man of culture"
As long as you don't use "conventional commits", we can be friends. Present tense is correct, but it doesn't matter too much.
Start polluting commit history with noisy prefixes and we'll start having problems.
You don't find the conventional commit prefixes to be useful for automation?
@@vickmackey24 No, because commit message subjects are not appropriate for a changelog. I update the changelog inside of the commit itself instead.
Changelog/automation stuff should be placed in body of the commit message, at least I prefer that approach