>74 characters path dependency is hell of a drug.
if you open a terminal window on mac with any kind of display 1080p, 4k whatever with any resolution you will still get a 80x24 terminal by default. Which is the whole purpose of `git log`. Using it on a terminal / ssh session / whatever.
What a good commit message looks like (2011)
11–20 of 100 posts
Re: What a good commit message looks like (2011)
#12Recently, 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…
Re: What a good commit message looks like (2011)
#13Re: What a good commit message looks like (2011)
#14Re: What a good commit message looks like (2011)
#15Recently, 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…
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.
Re: What a good commit message looks like (2011)
#16Re: What a good commit message looks like (2011)
#17 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.Re: What a good commit message looks like (2011)
#18Re: What a good commit message looks like (2011)
#19Should 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.