I've had the same feeling about the index, except I want the opposite setup. Instead of the index becoming a commit, I want to always commit my working tree, and for there to be a special sort of stash for the stuff I don't want to commit just yet. I want to commit what's in my working tree so I can test before committing.
The way it would work is that when I realize I want to do a partial commit I'd stash, pare down the changes in my working tree (probably using an editor with visual diff), test what's in my working tree, commit, and then pop the stash.
I had hoped that this would already be doable with git, but it isn't, at least not in a straightforward way. The problem shows up when you try to apply that stash. You get loads of merge conflicts, because git considers the parent of the stash to be the parent of HEAD, and HEAD contains a bunch of the same changes.
I'm sure there's some workaround for this, but every time I've asked people always tell me to not bother testing before committing!
Yes, that works, but it means I'm committing with a dirty work tree, so I can't really test before I commit.
You're probably going to say I shouldn't test before every commit, but I rarely work in a branch where the bar is as low as "absolutely no testing required". I generally at least want my build to pass, or some smoke tests to pass, and I can't reliably verify either of those with a dirty work tree. And actually, the fact that all of the commits on my branch are effectively going to end up in master (unless I squash) makes me want to to have even my feature branches fully tested.
> Yes, that works, but it means I'm committing with a dirty work tree, so I can't really test before I commit.
Ah, I see what you want to do now.
> You're probably going to say I shouldn't test before every commit
If have no business telling you what you should do. If you want to test before committing, your wish is my command
git stash --patch # Stash the bits you don't want to test
<do your tests>
git commit <options> # Commit the rest when the tests pass
git stash pop
<continue developing>
Interesting! I guess that works because the stash doesn't contain the changes I'm going commit now, and so it doesn't conflict (at least in simple cases).
I never use `--patch` (even with `git add`). I prefer to use vim-fugitive, which lets me edit a diff of the index and my working tree. It looks like being able to do something similar with stashes is a requested, but not yet implemented, feature for vim-fugitive: https://github.com/tpope/vim-fugitive/issues/236
$ git stash
$ git checkout stash@{0} -- ./
$ $EDITOR # pare your changes down
$ make runtests # let's assume they pass
$ git add ./
$ git commit
$ git checkout stash@{0} -- ./
$ make runtests # let's assume they pass
$ git add ./
$ git commit
*(In case it appears otherwise, this isn't actually supposed to be a defense of Git. Originally, this was 15 steps, but I edited it into something briefer and more straightforward.)
The way it would work is that when I realize I want to do a partial commit I'd stash, pare down the changes in my working tree (probably using an editor with visual diff), test what's in my working tree, commit, and then pop the stash.
I had hoped that this would already be doable with git, but it isn't, at least not in a straightforward way. The problem shows up when you try to apply that stash. You get loads of merge conflicts, because git considers the parent of the stash to be the parent of HEAD, and HEAD contains a bunch of the same changes.
I'm sure there's some workaround for this, but every time I've asked people always tell me to not bother testing before committing!