4 ms·
That requires everyone to have access to the repo, and to wade through it looking for changes to the relevant area of code you're working in. That sucks.
by ShadowBanThis01 3y ago
That requires everyone to have access to the repo, and to wade through it looking for changes to the relevant area of code you're working in. That sucks.
- tormeh 3y agoIn which situation would you not have access to the repo? I guess if it's a library or something, but libraries must always be documented in a different way to business code.
- ShadowBanThis01 3y agoMaybe you're a contractor. Maybe it's legacy code that has simply been archived. Maybe the network is down. Maybe there was a bad migration. Sidecars generally suck because they get lost.
- cerved 3y agoIf that's the case, you have bigger problems than documentation
- ShadowBanThis01 3y agoLike what?
- josephg 3y agoRelying on commits also fails as soon as feature branches start being squashed. And the comments in commits can’t be modified over time. You have to hope readers “git blame” the correct lines of your code. Just use comments.
- cerved 3y agoDon't squash. If you insist on it, I can't imagine why you wouldn't squash the commit messages You're not supposed to change commit messages. The correct lines to blame are the ones right there, not exactly rocket science
- josephg 3y agoIf your git squash contains all the commit messages, it’s a pain to figure out which commit message refers to which line of code. A comment goes right there. No tools needed. Mutable. Readable. Contextually in place. And you can even add comments while coding without waiting for the commit. Is typing // really so much effort?
- cerved 3y agoNo it's not and neither is writing a proper commit message. That's why you do both, but most of it goes in the commit. Like in the Git project