3 ms·
I don’t want to pollute a real branch with crap. I know how to rewrite history getting rid of it all, but I’d rather not. I prefer a bright line between tested,
by erik_seaberg 3y ago
I don’t want to pollute a real branch with crap. I know how to rewrite history getting rid of it all, but I’d rather not. I prefer a bright line between tested, quality work with messages ready for review, and whatever I happened to be in the middle of (that I may or may not decide to abandon later).
- scubbo 3y agoFair enough! Just for the purposes of comparison - my own "bright line between [good and bad]" is "does the commit message just contain 'WIP', or is it actually fully written-out?" - but I can see that "is the work committed or not?" also works. Thanks for explaining!
- erik_seaberg 3y agoWhat worries me about WIP commits is that dropping them via rebase -i might not be trivial if quality commits later depend on them.
- scubbo 3y agoCertainly! That's (one reason) why I'd _never_ drop a commit while doing `rebase -i` - just squash everything into a single (well-written) commit once it's ready to be reviewed! On some _very_ rare occasions, I might find that, by the time I've gotten the change to a reviewable state, it's actually too large to be meaningfully reviewed in one go, in which case I'll go back and retroactively (re-)implement it reviewable-chunk-by-reviewable-chunk (on a different branch), and get each of them reviewed and merged in turn. But, 99% of the time, I simply: * use WIP commits as "checkpoints" along the way while implementing * get to a minimal mergable change * use `rebase -i` to squash everything into a single, well-written, reviewable commit * rinse and repeat