3 ms·
This would only seem to work for relatively fine grained commits or projects in maintenance mode. Apart from that, to rigorously apply it would break the autho
by zmmmmm 13y ago
This would only seem to work for relatively fine grained commits or projects in maintenance mode.
Apart from that, to rigorously apply it would break the author's own advice or common sense source control practise - suppose I make 4 changes in separate files to fix a bug. Do I check them in separately so that I can put my pseudo code comments into the revision history? Now I have broken the atomicity of my revision history. If I check them in all together do I type a whole essay into the revision history about why each change was made in each file? It'll quickly all fall apart.
It also relies on the reader recognizing that they need to be curious about the code here. What it if didn't look so curious? It could easily get cleaned up or modified without a comment to alert the reader.
For people and projects in specific contexts it can work but there are plenty of situations where this is a terrible idea.
- mattdawson 13y agoTotally agree with the "might me good for maintenance mode" sentiment. I'm working on a pre-1.0 project. I'm thinking about the few commits where I was first implementing localStorage caching. Tons of files were effected on each commit. If there was a particularly tricky line in there (there were several), how would I have specified it in a commit? That'd be extremely hard to read when compared to the alternative of putting the comment above the code.
- pseut 13y agoHonestly, I think your example is a better demonstration of this than the article's. You make a change in four places, make a single commit, and then someone reading the code later can use the VCS to find all of the relevant parts of the code that deal with any particular line they're looking at.