4 ms·

Oh, I totally agree with all your use cases for committing, I'm just wondering why the reset. I would either go off on another branch to preserve my temporary w

Oh, I totally agree with all your use cases for committing, I'm just wondering why the reset. I would either go off on another branch to preserve my temporary work and then clean that up and commit or merge to one of the main branches or I would just push all my intermediate work.

ninkendo 5y ago
The reset is just a straightforward way to squash your work into one commit without much fuss. A typical workflow for me: $ git commit -a -m "WIP" # picture this, but 100 times as I go $ git reset $(git merge-base main HEAD) # Reset to the merge-base to avoid reverting upstream work $ git diff # Get a nice overview of everything I've changed, to aid in crafting a nice commit message $ git add . $ git commit # Type up a nice commit message describing the whole change Contrast this with using `rebase -i` to squash: $ git commit -a -m "WIP" # picture this, but 100 times as I go $ git rebase -i $(git merge-base origin/main HEAD) # rebase to the merge-base because I don't want to deal with merge conflicts yet $ # search/replace 'commit' with 'squash' in a text editor $ # save/quit $ # get prompted for new commit message, type it out $ # save/quit They both feel like the same amount of typing to me, but `rebase -i` thrashes my working tree around with each commit, which has a habit of confusing my IDE quite a bit and breaking its build cache. Also, I like the `git diff` step in the reset workflow because it gives me a nice reminder of what my change looks like, which helps inform how I should word my commit. So I use reset. If I want to keep my intermediate work locally for posterity, I usually use `git branch prprep/<bug_number>_unsquashed` or something so that I can dig it up later if need be. I don't push any of my `prprep/` branches.
Double_a_92 5y ago
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

The reset is just a straightforward way to squash your work into one commit without much fuss. A typical workflow for me: $ git commit -a -m "WIP" # picture this, but 100 times as I go $ git reset $(git merge-base main HEAD) # Reset to the merge-base to avoid reverting upstream work $ git diff # Get a nice overview of everything I've changed, to aid in crafting a nice commit message $ git add . $ git commit # Type up a nice commit message describing the whole change Contrast this with using `rebase -i` to squash: $ git commit -a -m "WIP" # picture this, but 100 times as I go $ git rebase -i $(git merge-base origin/main HEAD) # rebase to the merge-base because I don't want to deal with merge conflicts yet $ # search/replace 'commit' with 'squash' in a text editor $ # save/quit $ # get prompted for new commit message, type it out $ # save/quit They both feel like the same amount of typing to me, but `rebase -i` thrashes my working tree around with each commit, which has a habit of confusing my IDE quite a bit and breaking its build cache. Also, I like the `git diff` step in the reset workflow because it gives me a nice reminder of what my change looks like, which helps inform how I should word my commit. So I use reset. If I want to keep my intermediate work locally for posterity, I usually use `git branch prprep/<bug_number>_unsquashed` or something so that I can dig it up later if need be. I don't push any of my `prprep/` branches.

Double_a_92 5y ago

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.