That seemed strange to me given multistage compressors. Maybe 3:1 is true for a micro turbines, but for larger jets wikipedia says the pressure ratio is 30:1 to 40:1 citing the Trent 900 at 39:1 and the GE90 at 42:1.
Which according to the same article says that a 40:1 PR is equivalent to a 15:1 compression ratio.
#2313 Change expected value to a float field.
django-haystack stores decimal fields as strings internally.
This means that when we order by expected value small
values (e.g '9e-08') are sorted before larger values.
I prefer to keep such comments in the code, not in the commit message. It is highly unlikely that anyone coming to do some changes to that part of the code would go and read a year-old commit message that he isn't even aware exists.
There is a difference tough, a very subtle one. A commit body should describe the rationale of the change, i.e. any decisions that had to be made or trade-offs in light of developer discussions and so on. Basically a description of the issue being solved. These things are rarely needed in the code itself, as the code will most likely feature new things and the old things are history.
Some commits even feature implementation details, and those I agree with you sometimes it makes sense to include them in the code. However most implementation details replace old ones, and this is transition should be explained in a commit since this is the perfect place for it.
Here is an random example from the linux kernel, which is guaranteed to do what I described: http://goo.gl/QdKNnJ
Try using git blame. It tells you what change caused a line to happen. I often use it to find out exactly what issue caused a seemingly crazy bit of code to happen. As the code goes away, so does the commit message - not necessarily so with a comment.
You can run git blame to get the information pertaining to that particular line of code. That's a really good way to document what a particular piece of code is doing and why at the time it was written.
You're right -- the diff answers the what, so being able to answer the why concisely is what makes a good commit message.
Ticket numbers are important context, but unless it is a one-off commit you can instead put that info in the merge commit (as if saying, all of these commits I'm merging were made as part of fixing Issue #17).
Some people like to use squash extensively for that reason, but then you don't have the same granularity when it comes to reverting individual bits of that commit without reverting the entire bugfix. (This assumes that every commit leaves the code in a working state with passing tests).
I guess in that scenario my preference would be to amend the cherry-picked commit's message to include why it was cherry-picked.
The alternative in your case (leaving it as-is, with an issue number) implies that the entire commit addresses that particular issue number, which may not be true. (It may be part of a series of commits for that issue)
I think the point was mostly that 'lol' or 'meh' is a completely useless comment. It's true that there's a lot of room for improvements in the given example. Still, they do provide some context to people who actually understand the application they are working on.
Does anyone know of good open source project that uses Git messages extremely well that we could use as an example?
The Data Protection Act
Under the Data Protection Act, we have a legal duty to protect any information we collect from you. We use encryption software to safeguard your data, and keep strict security standards to prevent any unauthorised access to it.
I find when I have to re-factor code around the tests it means the code wasn't very good in the first place.
The author complains about re-factoring code into smaller testable functions. I completely disagree. Code structured as small easily understood functions which do one thing and have obvious inputs and outputs is good code which is much easier to extend and modify.
Yeah, that's one of the article's weaker spots. But as a rule, I'd tend to interpret imprecise statements like that charitably. He's not saying that small, clear functions are bad, but that splitting functions for the purposes of testing is counterproductive. He's not saying anything about splitting for clarity and focus.
This. I didn't even need to learn this the hard way, just had to read back some of my earliest teenage code (obviously not for any type of "production" setting) and hear enough of these scary stories to decide once and for all, it's really not that hard or big of a deal to be professional about these kinds of things.
Same goes for code comments. Unless it's a really, really good joke that won't offend if it happens to show up anywhere, or over your shoulder.
I was officially forbidden in my old job to write error messages at 3AM. Code was ok. But text - not after а high ranking client saw an error message. Its good that during the meetings with him we both were (in)appropriately vulgar and offensive so only my manager was shocked.
I'd be willing to bet that the article was written on the 11th or even before that. The campaign started with a nearly impossible goal, unless Obama himself had come out to declare surrender, they were always going to be able to print that.
I'm not sure I fully understand your comment. My understanding of this is that even after the revised accounts the auditor was still unwilling to put his name on the line. The implication in my eyes is that the books are still in pretty bad shape and could be worse.
Is there some reading of this that I'm not getting?