4 ms·
My pet peeve has always been the staging area. It encourages partial commits which couldn't have been tested because they never actually existed in the filesyst
by prodigal_erik 15y ago
My pet peeve has always been the staging area. It encourages partial commits which couldn't have been tested because they never actually existed in the filesystem.
I like rewriting history, though. If I commit A then B, then realize A was wrong, I test and commit a fix then autosquash it so my history goes A' then B. Historical commits which didn't work are worse than useless, and if someone branched from them, the sooner we all figure it out and fix it the better. And the ugly truth will still be there in the reflog for a month.
- MatthewPhillips 15y agoCould you explain your first point a little more, I'm not following what you're saying?
- prodigal_erik 15y agoWhen I make two changes to foo.c, and use "git add --patch" to apply one change but not the other to the staging area, my next commit will contain a version of foo.c that was never present out in my working copy where I could compile it.
- spacemanaki 15y agoGit's stash and clean commands make it possible to test partial commits built up in the staging area pretty easily. There's even a section of the man page for stash that's titled "Testing partial commits". I think this is essentially the flow described there: emacs foo.c # make two changes git add --patch foo.c # stage only one change git stash save --keep-index # stash changes not yet staged git clean -f # delete untracked files, like build artifacts # now the files on disk are in the same state as what you are about to commit Sure, it's more complicated than just not having a staging area, but it can be really useful, and it's really cumbersome to manually tease apart changes in the same file.
- prodigal_erik 15y agoThanks, I had missed that. It's almost as handy as the --patch option "git stash" didn't have.