The 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.
Just 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.)
A 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.
arccy|7 months ago
oxidant|7 months ago
0cf8612b2e1e|7 months ago
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|7 months ago
(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.)
andrewaylett|7 months ago
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|7 months ago