351–360 of 389 posts
Earlier quoted context omitted.
> And the subject line should complete the sentence "If this commit is applied, it will...". I kind of do it like this. Others use subjects that complete the sentence "This commit...", so their subjects will start with "adds", "fixes", etc. Though that adds one or two extra characters!
Like many of the pedantic things we like to argue about, I think teams/projects should choose consistency over prescription.
Earlier quoted context omitted.
> And the subject line should complete the sentence "If this commit is applied, it will...". I kind of do it like this. Others use subjects that complete the sentence "This commit...", so their subjects will start with "adds", "fixes", etc. Though that adds one or two extra characters!
Like many of the pedantic things we like to argue about, I think teams/projects should choose consistency over prescription.
This gives me ideas. My commits are usually short and sweet - to the point. I document my code very well, however. One of my strengths in a previous life as a Master Automobile Technician was the ability to document the entire process -- from duplication of a concern, to troubleshooting, to correction, to verification...it's literally how I got paid (which I never understood why so many automotive techs took short cu…
Commit messages should describe why you're doing something ("X asked", or "[reams of supporting evidence why this needed to be made faster but more confusing]"). It provides context to current reviewers, and future archeologists who wonder what you were drinking at the time. Perhaps you had a good reason for doing [insane thing X]! Perhaps you didn't. If you didn't write it down, they might change or leave it, and break something or prevent something from getting a proper fix.
Code comments should be notes to code-readers that are relevant at all times until changed or deleted. "How to use this", "beware changing X", "Z is hot garbage and should be replaced if used for Q". Ideally you'll have asserts or tests or something that actually enforce this, but of course that's not always a realistic option. Comments in code will follow the code around, and don't require chasing code history through N layers of refactoring and indentation-wars, which is what makes commit messages mostly inappropriate for needs like this.
Earlier quoted context omitted.
Final paragraph: > All in all, I believe this proves that software developers as a whole and as a culture produce worse results than drug addicted butt fucked monkeys randomly hacking on typewriters while inhaling the fumes of a radioactive dumpster fire fueled by chinese platsic toys for children and Elton John/Justin Bieber crossover CDs for all eternity. I also nominate this commit.
Pure, rage-filled, git commits are possibly the most honest form of art.
OR you could just write Replace invalid ASCII char. Fixes rake error 'invalid byte sequence in US-ASCII'. I don't want your entire life story in my commit log.
> I don't want your entire life story in my commit log. I[1] want enough debug information in the commit log to be able to reproduce the issue without having to go on web hunts to understand the problem. Especially when the change appears to be trivial on the surface, because these are the ones that can turn out to be rabbit holes. I don't want to have to interrupt you to get this information because you didn't write…
Earlier quoted context omitted.
Hmmm, I've always believed that no commit should break a build, even if you're committing the fix right after. Otherwise you're going to cause problems for `git bisect` or other practices of going through the history to find where a problem may have started. Do other people commit breaking tests and then fixes?
I might be missing something basic here. Isn't the "no commit should break a build" impossible to enforce on a codebase where you need to push a commit to run the tests? Something where you can't test locally, like when testing on multiple architectures or when the tests just take too long for a laptop.
I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing somethi…
I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing somethi…
Every commit message must start with JIRA ticket number
The branch is called feature/-
The commits contain usual commit messages. When merging, changes are quashed. The final commit message is similar to the branch name and includes the ticket and a short description, which is similar to the mentioned pattern (bump/add/change/whatever).
Earlier quoted context omitted.
Yeah. People who use the term "retarded" that way are stupid, no matter how smart they are.
I don't recommend you to join chats in competitive online games.