4 ms·

That's why it's a flag. You could do git reset HEAD^ && git stash instead Also, git reset ---hard HEAD^ deletes nothing. The commit HEAD was pointing is not d

• glandium 5y ago
  It does delete whatever uncommitted changes you had.
  • still_grokking 5y ago
    Well, that's the purpose of "reset". You explicitly ask the system to delete whatever uncommitted changes you had. If you type in "rm -rf ." there will also be no "warning" about what happens next… I for my part don't like systems that after giving it a command very explicitly asks me whether it should really execute that command. "You just pressed the button to delete those files. Do you really want to delete those files?" "Oh, no sorry. I'm the operator of this system but I press buttons randomly just for fun. Actually I have no clue what I'm doing. Thanks for that pointer! Please ask me also the next time, as I'm not going to remember what this button does. In fact I have no clue at all what I'm doing." Dude… Git is not a backup tool. (Even you could use it as such). If you need a backup, make a backup. I'm aware of the fact this this comment may sound impolite to some. But out of my perspective it's a feature and not a bug that unixy systems traditionally don't ask stupid questions after you told them to do something. It's an attitude of respect towards the operator: The system assumes that the operator knows what he is doing. Asking questions in the style of "do you really, really want me to do what you just said" is on the other hands side just extremely rude against the operator—as the systems assumes the persons in front of the keyboard does not know what he is doing at all! I hate systems with build in "support wheels". The creators of such systems obviously thinks their users are cretins, and that's very annoying.
    • naniwaduni 5y ago
      > But out of my perspective it's a feature and not a bug that unixy systems traditionally don't ask stupid questions after you told them to do something. It's an attitude of respect towards the operator: The system assumes that the operator knows what he is doing. By the way, have you ever run across a situation where the standardized behaviour of rm without -f (to wit, check the permissions of each non-directory, and, if it's not writable, prompt if stdin is a terminal)?
    • seoaeu 5y ago
      Humans make mistakes. Well designed systems are resilient to those mistakes. That doesn't mean prompting after every single command, which as you point out would be super annoying, but it does mean making operations reversible unless there is a very good reason they cannot be. Essentially every system designed in the last few decades has a concept of a 'recycle bin' or undo feature for deletions at least for a short window of time.
    • glandium 5y ago
      > Well, that's the purpose of "reset" Well, that's the purpose or "reset --hard". "reset" alone doesn't do that. That's the difference with "rm". With "rm" you expect something to be removed. "rm" may fail because you gave it a directory but you forgot "-r". Or it may fail because you don't have the right to the parent directory or something. But it is pretty much expected that something will be deleted if you run "rm". From the perspective of people who don't understand the difference between "git reset", "git reset --hard", etc., that some of those will destroy their data but not others, is part of the confusion. And when they picked one instead of the other and lose their modifications, they'll blame git from being confusing to use, not themselves for not doing a backup before running a command in their source directory with a program that is used to manage source directories.
  • cerved 5y ago
    true, if they are modifications and deletes but not additions it'd be trivial to modify that behavior to refuse to continue in such a case if you want double seatbelts also, if the changes were staged they were recorded in the database and remain there