41–50 of 100 posts
Earlier quoted context omitted.
Also: avoid using comments where proper names would suffice: // cleans responses function zrgfy(response){ ... } should be something like: function cleanResponse(response){ ... }
My rule of thumb in commenting is that I comment the why or how, not the what... Unless the what is sufficiently non-obvious, in which case it is usually prudent to have a really good explanation of the why, as well.
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 …").
With that one, the way I see it is that when people use the past tense, the git history becomes a work log, i.e. what the committer did; "I fixed bug...". It shouldn't be like that, the commit should describe what the commit does, i.e. "Fix bug" or "Fixes bug". the latter uses more letters though, which is probably why I see a preference for the "Fix bug" format due to the (soft) 50 character subject constraint.
I don't care if this was easy or hard or the bug was non-obvious or if you used a weird trick.
I do care what the change does: fixes a race condition, adds a new file mode etc. Those changes matter at the time (what's new in the code?) and when looking backwards (ah, here's where that new file mode was added, let's see what was going on then).
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…
When practical, of course.
In this case, git could simply give a "are you sure you want to commit with these long lines?" warning.
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.
m-X auto-fill-mode. You can add this to other modes automatically. I almost always have it on. Added to Emacs in 1977.
Earlier quoted context omitted.
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…
Web browsers line break text dynamically just fine - as do, well, text editors. 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 fo…
Earlier quoted context omitted.
m-X auto-fill-mode. You can add this to other modes automatically. I almost always have it on. Added to Emacs in 1977.
The point is that people shouldn't be littering their text with hard line breaks just to support software that can't do word-wrapping properly. That your editor can do this doesn't mean you should . It might make the text look a bit prettier in an 80 column terminal, but it makes it worse pretty much anywhere else.
How can the software guess whether a given line should be wrapped (text), should not be wrapped (code), should be wrap-indented (list item) or should be wrap-prefixed (quote block) when it's only given raw bytes assumed to be text without further information?
Trying to get something to run on Heroku involved making lots of small changes just to get things to run on the server the same as on my dev machine.
When you do that 10 or 20 times the commit message become somewhat meaningless.
Earlier quoted context omitted.
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…
OPs point remains. It's git's job to tell me its limitations. Not my job to adapt my tools to it. When practical, of course. In this case, git could simply give a "are you sure you want to commit with these long lines?" warning.
Earlier quoted context omitted.
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
What is "The Git Killer"?
Earlier quoted context omitted.
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…
Web browsers line break text dynamically just fine - as do, well, text editors. 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 fo…