4 ms·

Starting back around 2009, I started marking bug fixes in git with the first line containing "Bug fix---description". For example (from my gopher server [1]):

by spc476 6y ago

Starting back around 2009, I started marking bug fixes in git with the first line containing "Bug fix---description". For example (from my gopher server [1]): a12c3fd Bug fix---sample forgot POST method. 0b1bce2 Bug fix---grab guid when only given numeric uid. 31408da Bug tracking---crash because filename is nil? d993265 Bug fix---Clean the display text to prevent broken index files. 47e98e8 Bug fix---line comments were broken in .port70 files. I do the same at work. I got the idea from Donald Knuth, who wrote a paper about classifying each error in TeX [2]. I didn't go as far as he did, but I still have his list handy: * Algorithm * Blunder * Cleanup * Data * Efficiency * Forgotten * Generalization * Interaction * Language * Mismatch * Portability * Quality * Robustness * Surprise * Typo [1] https://github.com/spc476/port70 https://github.com/spc476/port70 [2] "The Errors of TeX" <https://yurichev.com/mirrors/knuth1989.pdf https://yurichev.com/mirrors/knuth1989.pdf>

l0b0 6y ago
Very similar to Conventional Commits[1], with this structure: <type>[optional scope]: <description> [optional body] [optional footer(s)] It's supported by pre-commit[2], which is an excellent way to set up commit rules and linting. [1] https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/ [2] https://pre-commit.com/ https://pre-commit.com/
- auslegung 6y ago
  At first, conventional commits sounds neat because they say you can > Automatically generating CHANGELOGs. > Automatically determining a semantic version bump (based on the types of commits landed). And I would really like those features. However it seems like this assumes 1 commit per feature, which I think is not the conventional wisdom. Am I missing something? For example, the feature is to add a new page to the site where the user can view all their posts. That should break down into several commits: add new route, add parser on frontend, add html structure, etc. But each of those commits would have to start with `feat: add route to fetch user's posts` and so on. Wouldn't that result in a unhelpfully verbose changelog, when the changelog should really feature one line: "Allow users to view all of their posts in one place"

by spc476 6y ago

l0b0 6y ago

Very similar to Conventional Commits[1], with this structure: <type>[optional scope]: <description> [optional body] [optional footer(s)] It's supported by pre-commit[2], which is an excellent way to set up commit rules and linting. [1] https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/ [2] https://pre-commit.com/ https://pre-commit.com/

auslegung 6y ago
At first, conventional commits sounds neat because they say you can > Automatically generating CHANGELOGs. > Automatically determining a semantic version bump (based on the types of commits landed). And I would really like those features. However it seems like this assumes 1 commit per feature, which I think is not the conventional wisdom. Am I missing something? For example, the feature is to add a new page to the site where the user can view all their posts. That should break down into several commits: add new route, add parser on frontend, add html structure, etc. But each of those commits would have to start with `feat: add route to fetch user's posts` and so on. Wouldn't that result in a unhelpfully verbose changelog, when the changelog should really feature one line: "Allow users to view all of their posts in one place"