I don't get this "afraid of losing something" mindset at all. In fifteen years, I've "lost" some minor changes maybe 3 or 4 times, and this was mostly with SVN, which does not have the safeguards that Git has. The only thing that I am moderately afraid of is pushing to the wrong remote branch.
> I don't get this "afraid of losing something" mindset at all. In fifteen years, I've "lost" some minor changes maybe 3 or 4 times, and this was mostly with SVN, which does not have the safeguards that Git has. The only thing that I am moderately afraid of is pushing to the wrong remote branch.
I can lose something for you in 2 seconds in git. Have fun e.g. recovering from this:
> "I can lose something for you in 2 seconds _in_ git."
You just demonstrated losing something that was not in git... All you've demonstrated is that neglecting to put something into git is a good way of losing it.
git checkout [<tree-ish>] [--] <pathspec>...
Overwrite paths in the working tree by replacing with the contents
in the index or in the <tree-ish> (most often a commit). When a
<tree-ish> is given, the paths that match the <pathspec> are
updated both in the index and in the working tree.
As 'widget' is a path (and not a branchname as most often), local changes will be overwritten. Together with `git reset --hard` this is a bit a dangerous operation. I must say, that I don't fully understand the help text and just remember that `git checkout <path>` throws away my local uncommitted changes.
Also note that 'widget' could've also easily been a typo for a branch (maybe they meant 'widgets' or something). Meaning that even if you only stick to uses of git checkout for branches, you're not safe (unless you're infallible).
Probably a feature given how many gazillion meanings they've given to checkout intentionally, but I have no clue. Hopefully it got the point across though ;) and I'm pretty sure it's not the only way to lose info in git...
In a near future, hopefully we will have two new commands, git-switch and git-restore. The former is only about switching branches, the latter restoring files. Then you can stay away from the overloaded git-checkout.
Apparently I'm warned when I do this using SmartGit; if you are unable to safely use the CLI tool, maybe you should switch to a safer tool and leave the CLI tools to power users?
Way to suggest only incompetent people lose data like this.
But yes, GUIs do prevent this to a decent extent. Unfortunately git is not a tool for which switching to a GUI before you're comfortable with the CLI is a good idea. SVN is, but not git. I say this from personal experience as a TortoiseGit user. You really gotta learn the command-line first.
What you did there is the equivalent to a `revert` in SVN ... I'm not sure what the issue is? Why would you checkout `widget` and not expect local changes to be overwritten? Like, that checkout reverts is one of the first things you learn with git ...
> What you did there is the equivalent to a `revert` in SVN ... I'm not sure what the issue is? Why would you checkout `widget` and not expect local changes to be overwritten? Like, that checkout reverts is one of the first things you learn with git ...
Why would you sudo rm -rf / and not expect to destroy your system? Why is --preserve-root the default when that's clearly not what the command means? Like, that -rf wipes everything recursively is one of the first things you learn with rm...
(P.S. also note the question wasn't even about whether this is expected behavior, it was just about whether it's possible to lose information when using git.)
Come now, that's being a bit hysterical/hyperbolic. There's plenty of other things you could do in the course of your command-line activities that are at least as destructive.
I know your example is meant to be trivial but there are plenty of ways when you're mucking about with pipes to ruin your day.
Like I say, "it is known" that git checkout is destructive, and while I can sympathise that perhaps the "-rf" is implicit I honestly can't see how you'd end up doing something like that in day-to-day activities, and if you did ... well if you'd spent any significant amount of time on it it probably should have been checked in anyway.
EDIT if you want to see some "good" examples of how you can inadvertently trash everything take a look at https://svnvsgit.com/ (warning, not as impartial as the title might suggest).
I'm not being hyperbolic or giving a trivial example (whatever that's supposed to mean), I was completely seriously pointing out that people used to apply your exact same victim-blaming logic to that same scenario until others finally made them come to their senses and realize that, just because the user happens to type in a command that tells the computer to shoot him in the face, that doesn't necessarily mean the computer should actually go ahead and shoot him in the face. Somehow you managed to take those 6 words out of context and focus on bashing the example while ignoring the actual real problem I was illustrating with it in your reasoning.
A "trivial example" is where you demonstrate a concept using a simplified or trivial scenario. It's quite a common term, and I didn't mean it as a put-down.
"victime-blaming", "shoot in the face" .. I feel are fairly extreme terms to describe what's happening here. The scenario you've concocted is really only one that could occur where you didn't know what you were doing and Git (or the command line) aren't really things you'd end up using if you didn't know what you're doing.
It's not a concocted scenario, the cli command in question explicitly has a property that defaults to preventing it from doing what it should do, unless you override the property. Explicitly because it's so destructive when you do it by mistake.
