3 ms·

Often I'll work on a large change and make sure that it is working before I start crafting my commits. By the time I get to that point, I realize that I've actu

by uiri 9y ago

Often I'll work on a large change and make sure that it is working before I start crafting my commits. By the time I get to that point, I realize that I've actually made three separate subchanges so I do partial stages to create each commit. I use git status -s and git diff quite a bit as a sanity check (for things like whitespace) and to do first party code review before I send anything out. The staging area is a core part of my personal git workflow pre-commit. It seems to be producing good results so far.

masklinn 9y ago
> I realize that I've actually made three separate subchanges so I do partial stages to create each commit. You can trivially replicate that without staging by amending the HEAD commit, or building a bunch of partial commits then folding them with rebase -i. You can even do that automatically by committing with --fixup or --squash
- uiri 9y ago
  That assumes that I'm making multiple smaller commits along the way. I'm not. Without staging, I'm stuck making one big commit. Splitting a single big commit into multiple smaller commits with an interactive rebase is dependent upon the staging area too.
  - masklinn 9y ago
    > That assumes that I'm making multiple smaller commits along the way. I'm not. Without staging, I'm stuck making one big commit. Errr… no you're not. `commit -p` exists.