I recommend "commit early, commit often" approach instead -- and rebase/squash before making a PR.
For those temp commits, I found out that even bad commit messages which would not be acceptable in any serious codebase ("reafctored foowidegt", "starts up but crashes in 3 sec", "cannot find unistd.h") are still very useful. And of course those commit messages are great placeholders for random notes ("TODO need to add unit test for zero input", "still need to hook up to main class")
That's fair and usually all you need, but here are two reasons I still find my script useful:
* The commits are made on a not checked-out branch. This means `git diff` and my editor continue to show me my changes compared to the last "proper" commit.
* The fine-grained commits created with `git snap` are retained by default since they aren't meant to be squashed.
3 comments
[ 3.6 ms ] story [ 20.8 ms ] threadFor those temp commits, I found out that even bad commit messages which would not be acceptable in any serious codebase ("reafctored foowidegt", "starts up but crashes in 3 sec", "cannot find unistd.h") are still very useful. And of course those commit messages are great placeholders for random notes ("TODO need to add unit test for zero input", "still need to hook up to main class")
* The commits are made on a not checked-out branch. This means `git diff` and my editor continue to show me my changes compared to the last "proper" commit.
* The fine-grained commits created with `git snap` are retained by default since they aren't meant to be squashed.