31–40 of 100 posts
Earlier quoted context omitted.
Highly disagree. As long as the code lives, the commit lives.
until the git killer comes along and the team decides how much history they are willing to migrate. I've seen it happen every 5(?) years across several companies. Ironically it's always the oldest commit messages that turn out to be the most valuable because newer changes people remember
The body of the commit message can be several paragraphs, and please do proper word-wrap and keep columns shorter than about 74 characters or so. That way "git log" will show things nicely even when it's indented. Software should help me, I shouldn't have to help it. Why doesn't git handle this formatting automatically? I shouldn't need to manually break lines for typographical (not paragraph) reasons.
That software is called a text editor and you can configure it to do the text wrapping for you. More seriously, it is quite hard to wrap text correctly after you submitted it. For example people add manual line breaks for structuring text and to separate things like quoted commands from the rest. It would be much more cumbersome to go back after a git commit to fix this, probably in multiple iterations until you get…
Using a text editor to automatically embed line breaks doesn't fix the problem: embedding line breaks in text for formatting is wrong semantically. Hard line breaks should mean something. Now I can't reflow the text to display it on a web page in a normal font, because I can't be sure of which line breaks are meaningful, and which are formatting.
Here's what, Tim Pope, our favourite vim nerd has to say about this: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... (Same, but with more words.) A point of contention seems to be the choice of the imperative, at least for the subject line. While I'm really used to it, both when reading and writing, many people seem to strongly prefer past tense ("Fixed bug …" instead of "Fix bug …").
Here's what, Tim Pope, our favourite vim nerd has to say about this: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... (Same, but with more words.) A point of contention seems to be the choice of the imperative, at least for the subject line. While I'm really used to it, both when reading and writing, many people seem to strongly prefer past tense ("Fixed bug …" instead of "Fix bug …").
The body of the commit message can be several paragraphs, and please do proper word-wrap and keep columns shorter than about 74 characters or so. That way "git log" will show things nicely even when it's indented. Software should help me, I shouldn't have to help it. Why doesn't git handle this formatting automatically? I shouldn't need to manually break lines for typographical (not paragraph) reasons.
That software is called a text editor and you can configure it to do the text wrapping for you. More seriously, it is quite hard to wrap text correctly after you submitted it. For example people add manual line breaks for structuring text and to separate things like quoted commands from the rest. It would be much more cumbersome to go back after a git commit to fix this, probably in multiple iterations until you get…
Great system about our commit system at work is that every commit starts with the name of a ticket of our ticket system (jira) so you can go back to that ticket whenever that commit comes up anywhere and understand the commit better
even better systems allows to link tickets to commits.
We also use this convention with gitflow, so our branches are named eg, feature/PROJ-1234-added-new-ui or bug/PROJ-2345-fix-new-ui. This also lets JIRA find and link them, and makes pull requests get the ticket number in their title by default as well (since its based on branch name).
The last bit is just a short human-readable thing to make branches easier to look at and find, because the initial way we started using gitflow:
feature/
feature/PROJ-2286
feature/PROJ-2352
feature/PROJ-2367
feature/PROJ-2382
feature/PROJ-2385
bug/
bug/PROJ-2240
bug/PROJ-2323
bug/PROJ-2393
Recently, I try to write the first line of my commit messages so they describe what the system now does, compared to before the commit. This makes reading the history much more fun. Like: Validation of email addresses now sends a test email to the user, instead of the old regex that never worked. This style does not work for all kinds of changes, but when it works, it creates a nice history of how the functionality o…
Including the old bit is meaningless noise there. I'd use something like "Improve email validation" or "email: send a test email as validation" or such. The body is where you can describe previous behaviour and give more details.
Validation of email addresses now sends a test email to the user, instead of the old regex that never worked.
> Send test email to user for email address validation > > This change was done because the old regex never worked; see also {link} and {link} for more information.
as an example. Ideally the header also contains a hint to the module the change was done in, etc. The linux kernel commits take this to (what comes across to me as) the highest levels.
Here's what, Tim Pope, our favourite vim nerd has to say about this: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... (Same, but with more words.) A point of contention seems to be the choice of the imperative, at least for the subject line. While I'm really used to it, both when reading and writing, many people seem to strongly prefer past tense ("Fixed bug …" instead of "Fix bug …").
If the project uses past tense, use it. If you want to change the convention, that's okay too, but everyone has to change.
It's exactly the same issue as coding style. If you can look at code or commit messages and figure out who wrote it based purely on style/formatting, you're doing it wrong (or rather: the person using the inconsistent style/format is).
The body of the commit message can be several paragraphs, and please do proper word-wrap and keep columns shorter than about 74 characters or so. That way "git log" will show things nicely even when it's indented. Software should help me, I shouldn't have to help it. Why doesn't git handle this formatting automatically? I shouldn't need to manually break lines for typographical (not paragraph) reasons.
Added to Emacs in 1977.
Should be noted, it is often tempting to describe everything about the change in the commit description rather than comments in the code. Remember, git commits disappear from sight pretty soon and become fossils, whereas there may be something important that should be said in the code itself.
I think that on the contrary, everything should be in the commit. The commit message is dated, it has an author and a context. How often do you come across stray comments which shouldn't be here because the code got refactored away? Commis are often just a git blame away anyway.