3 ms·
> Because that doesn't really matter. Ok, so maybe rather than have this file we should run “git log | grep BANNED” and build a list of functions from that? Or
by orf 6y ago
> Because that doesn't really matter.
Ok, so maybe rather than have this file we should run “git log | grep BANNED” and build a list of functions from that? Or maybe we could change all error messages to be “go look at the commit history to work out why this happened”.
No? Maybe putting context in source files (or better yet, an error message!) rather than in a side channel like the commit message has value when it comes to understanding and updating, and it won’t be lost under the weight of future commits.
- deleted 6y ago[deleted]
- capableweb 6y agoYour source code should describe what the program should do today. It should not contain all historical artifacts about your source code, as it'll grow to big and unmanageable then. Instead, use Git to store temporal information, data that is about change and reasoning behind it. Git is basically a timeline, instead of hard facts of today. That's why it makes sense to describe the background and reasoning behind a change in a Git commit, instead of inside your source files as comments.
- orf 6y agoTotally agree, which is why nobody is suggesting adding the background and reasoning behind the change to the source file as a comment. They are suggesting adding a more informative error, which may include a subset of that background and reasoning. An error message that points you to the functions you should use instead is infinitely more informative than one that says “this is banned. Bye.”
- jorl17 6y agoPrecisely.