4 ms·
I can relate to that. I don't like those WIP commits on a feature branch (when the program is crippled or even doesn't compile or doesn't pass the tests, when t
by conductor 11y ago
I can relate to that. I don't like those WIP commits on a feature branch (when the program is crippled or even doesn't compile or doesn't pass the tests, when the code is filled with temporary "printf" debug messages, etc.) to be in the history of the master branch.
Ideally, every commit that I'm making should be preferably not big, but logically complete and working. The problem is that sometimes I want to work on another branch and I have to commit in the middle of the work so I can checkout into the other branch in which case (without a squashing merge) the "offending" WIP commit would end up in the master branch's history.
- Estragon 11y agoman git stash
- jdfellow 11y agoalso very handy for working on multiple branches concurrently, git worktree --help
- kageneko 11y agoI can't trust git stash anymore. I mistyped something and it blew away a lot lot lot of work. So now I just commit stuff. If I want to get rid of the commit, I can follow it up with a reset.
- gcommer 11y agoI use commit amends (`git commit -a`) for continually updating these pseudo-stash commits.
- cname 11y agoIf you can't trust `git stash`, you can't trust git in general, because you can do all kinds of destructive things (which are usually recoverable).
- dahart 11y agoNot true. From the git stash man page: "If you mistakenly drop or clear stashes, they cannot be recovered through the normal safety mechanisms." Git stash is more dangerous than other git commands, and I've personally witnessed more people losing work with stash accidents than with commit accidents. There may be plumbing commands that can get you there like fsck but the fact of the matter is you are better off committing or branching, from a safety standpoint.