6 ms·
Counterpoint: Why should my println debugging get committed? They're not "important" for the final product but important for development.
by oxidant 1y ago
Counterpoint: Why should my println debugging get committed? They're not "important" for the final product but important for development.
- 0cf8612b2e1e 1y agoThe logic is once you are ready to commit you delete all of the debugging stuff. Otherwise you are committing an illusionary state of the repo that only existed by manipulating the stage. I am a black kettle here as I frequently commit individual lines amongst a sea of changes, but I do appreciate the theoretical stance of jj.
- steveklabnik 1y agoJust to be clear, jj makes it really easy to carry this sort of thing as a separate patch, so while it may be "committed," that doesn't mean it has to go into what you send upstream. (though for debug printfs in particular, the Right Thing is proper logging with log levels, but I myself love printf debugging and so sometimes don't do that either. Which is why carrying local patches is nice.)
- baq 1y agoThere is no Right Thing here. Practicality beats purity. The product (a snapshot of the source tree) should do what it needs to do, but getting there is not the product. It can be if you want it to be, but there is no upside to that.
- andrewaylett 1y agoA tool like pre-commit really helps here: it'll run against the staged files, before committing. Your CI tool really ought to be testing the commit too, at which point having a clean commit locally isn't necessary for correctness, only for avoiding needing to re-do your work. It's really important to catch bugs early, because it's a lot more expensive to fix them later -- even if only as late as in CI before merging.
- sunshowers 1y agoI think most people would use a logging library (maybe at the "trace" level) at that point.
- arccy 1y agoyou've obviously never encountered code which only works when println is added.
- oxidant 1y agoSchroedingers branching