Should these things happen? No. Do they happen? All the freaking time.
Aye, and with intention revealing names!
You were right, however, that the post was never about code quality or code comments. It was only about "history's great, yo; here's what you can do with it".
// This triggers layout. Needed for some browsers.
But agreed that you shouldn't require relying on history for this context. It's bad news. Yes code happens, but it should be obvious what it does (via clear code) and why (via comments as needed).
The example in the original post relies heavily on out of band documentation. Your suggestion of an intention revealing function name puts the same info in-band.
One should always ask themselves: Does my code depend on out of band information? If so, can we correct this?
I think the overall point of the article rings very true: great VCS habits pay dividends over time regardless of how well-crafted the code itself is.
Having a detailed code history isn't in any way an excuse to leave obscure code as is. If you have time to document it, you have time to make the code right.
In short, maintaining a clean code base has always higher priority than maintaining a clean log.
http://lsolum.typepad.com/legal_theory_lexicon/2003/09/legal...
this article is about recommendations of what to do ex post once a comment-less line of code has been committed in the past that you need to understand. arguments about ex ante things such as how it got there in the first place and how to prevent it from happening is completely orthogonal to the point of the article.
https://github.com/madrobby/zepto/commit/3d92f20966aa02dee82...
Which means the OP genuinely thinks that commits like this one are good practice, and the purpose of the article is to show how to deal with it.
Yet as it was argued above, commits like that should never happen in the first place.
Notice the code comment. I took it out for the example in the blog post to illustrate how we would deal if there was never a code comment in the first place.
I think the article as a whole is great in that it taught me some things you can do with git that I didn't know before (well, stuff I figured was possible, but didn't know the magical incantations). But it's hard to start reading it and really appreciate all that when the initial premise for explaining all that stuff was... well, someone having a severely bad day when it comes to writing clear code.
From my experiences in the real world and from reading comments here, I think there are a lot of people that disagree with that assertion, and it kind of makes me wish I worked in a field where I don't feel like I'm going insane on such a regular basis.
Code like this is extremely brittle with or without that git history, don't rely on it like a crutch as it makes the code obscure, and updating a line somewhere may leave other similar lines updated or not. If you wanted to update the triggerLayout function, you would have to go through the git commit log for every .clientLeft line to see if that one was or wasn't used for triggering layout...