Because, as the parent poster said, everything is immutable except the working directory. The working directory is the default place where all the work is done, as the name suggests. You have to explicitly move things from the working directory to the other areas in order for git to recognize it; the default is "do nothing".
On top of this, various git commands can delete things you've done in the working directory without any confirmation or warning (e.g. "git checkout [filename]"). And of course, so can various non-git commands (e.g. "rm [filename]"). If that happens, the work is permanently lost if there isn't another backup mechanism in place.
So they're not wrong, but the second sentence's implications are kind of glossed over. It's always confused me that git lets you lose work so easily, so a very long time ago I've always just made sure to put all of my programming projects in a Dropbox folder. I rarely mess anything up that badly with git, but for the few times I have, Dropbox version history has definitely saved me.
You should change the way you work with git. Commits are cheap. Really, really cheap. Commit all the time. Make "WIP" commits to remind you to squash them later. Your working directory is just like any other place on your filesystem. You can lose stuff if you do the wrong thing.
Yes, I do do this. But Dropbox is still a good safety fallback. I'm not committing everything for every line of code, but with VS Code auto-save, Dropbox is basically committing a version for every line of code.
It's useful even if I just refactor some code and change part of the refactor and then change my mind and want to go back to what I was initially trying. And it also helps if my hard drive dies or my laptop gets stolen, etc.
> Your working directory is just like any other place on your filesystem. You can lose stuff if you do the wrong thing.
Which means git is failing to do its whole job: keep the history of my work safe. I'd argue that git actually makes data on your filesystem less safe, because it pointlessly write-protects files in the .git directory, which encourages a bad habit of using rm -rf.
They are wrong, there are actions you can take in git that will cause you to lose your "immutable" history. Most accidental cases probably involve `git reset` or `git rebase`, but here's an example if you want to do it intentionally:
# Commit all changes and push to at least one remote so your changes are ""immutable""
rm -rf myrepo/
mkdir example && cd example
git init
# Repeat for each remote
git remote add remote1 https://origin.for/your/repo
git push remote1 --mirror --force
Congrats, you've lost everything! (Except for your backups, you do have backups right?)
`git reset` and `git rebase` will not lose anything that you have commited before. And force-deleting the remote stored repo is cheating (and prevented by default in quite a few services).
On top of this, various git commands can delete things you've done in the working directory without any confirmation or warning (e.g. "git checkout [filename]"). And of course, so can various non-git commands (e.g. "rm [filename]"). If that happens, the work is permanently lost if there isn't another backup mechanism in place.
So they're not wrong, but the second sentence's implications are kind of glossed over. It's always confused me that git lets you lose work so easily, so a very long time ago I've always just made sure to put all of my programming projects in a Dropbox folder. I rarely mess anything up that badly with git, but for the few times I have, Dropbox version history has definitely saved me.