3 ms·

Yeah I also don't see the need for it. Maybe if you often commit completely broken code with meaningless messages... But usually most commits we do at work are

Yeah I also don't see the need for it. Maybe if you often commit completely broken code with meaningless messages... But usually most commits we do at work are still proper little changes (even if it's just 2 lines of a huge feature) with meaningful information in the git message. I would not want to lose that when merging back into the main branch.

ninkendo 5y ago
> Maybe if you often commit completely broken code with meaningless messages Bingo. I do this all. the. time. I don't want anybody seeing it. I honestly couldn't imagine another way of working... commit early, commit often, I say. Hell, commit on a timer every minute, if that's your thing (I've never done this but totally understand people who do.) Leave the meaningful messages for later when you're actually ready to craft a PR. Honest question: if you avoid committing code unless it's working and you have a meaningful message to make, what happens if you screw up your editor undo, and you need to go back to where you were 10 minutes ago? This happens all the time for me... I undo a whole bunch and then accidentally type the "z" button into my buffer because I fumbled the keyboard, and now I can't "redo" back again. If I commit early and often, I can recover the work to where it was, even if it's not compiling yet. If I have to wait for my code to be basically "reviewable", I'd be screwed.
- Double_a_92 5y ago
  We usually work in a team of 2-3 on the same feature branch, so we can't push half broken things to out teammates. And the WIP commits can still be done, but locally. Then I clean them up everytime I push to the remote branch, but not when that branch is merged.
  - ninkendo 5y ago
    Of course I'm talking about local commits, who brought up pushing? I only push when I'm ready to. But turning my local WIPs into something I can push, is most easily done with the reset workflow (but to each their own.) It occurs to me that people like me might actually be quite rare, who use git almost entirely locally and rarely push. The only times I push are when creating a PR (hence all the resetting and rewriting first), or to back up my WIP work, if it's important. And even then it's to my own fork, and under a branch namespace that nobody would ever confuse with real code that should be reviewed.

ninkendo 5y ago

> Maybe if you often commit completely broken code with meaningless messages Bingo. I do this all. the. time. I don't want anybody seeing it. I honestly couldn't imagine another way of working... commit early, commit often, I say. Hell, commit on a timer every minute, if that's your thing (I've never done this but totally understand people who do.) Leave the meaningful messages for later when you're actually ready to craft a PR. Honest question: if you avoid committing code unless it's working and you have a meaningful message to make, what happens if you screw up your editor undo, and you need to go back to where you were 10 minutes ago? This happens all the time for me... I undo a whole bunch and then accidentally type the "z" button into my buffer because I fumbled the keyboard, and now I can't "redo" back again. If I commit early and often, I can recover the work to where it was, even if it's not compiling yet. If I have to wait for my code to be basically "reviewable", I'd be screwed.

Double_a_92 5y ago
We usually work in a team of 2-3 on the same feature branch, so we can't push half broken things to out teammates. And the WIP commits can still be done, but locally. Then I clean them up everytime I push to the remote branch, but not when that branch is merged.
- ninkendo 5y ago
  Of course I'm talking about local commits, who brought up pushing? I only push when I'm ready to. But turning my local WIPs into something I can push, is most easily done with the reset workflow (but to each their own.) It occurs to me that people like me might actually be quite rare, who use git almost entirely locally and rarely push. The only times I push are when creating a PR (hence all the resetting and rewriting first), or to back up my WIP work, if it's important. And even then it's to my own fork, and under a branch namespace that nobody would ever confuse with real code that should be reviewed.