News for hackers. Stuff that matters.
Re:Git undo: We can do better by cerved on Monday June 21, 2021 @04:57PM (#27584374)
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 deleted. You have to work really hard to delete that commit accidentally

Re:Git undo: We can do better by glandium on Monday June 21, 2021 @05:40PM (#27584881)
It does delete whatever uncommitted changes you had.
Re:Git undo: We can do better by still_grokking on Monday June 21, 2021 @07:08PM (#27585723)
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.

Re:Git undo: We can do better by seoaeu on Tuesday June 22, 2021 @12:00AM (#27587847)
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.
Re:Git undo: We can do better by glandium on Tuesday June 22, 2021 @02:54AM (#27588753)
> 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.

Re:Git undo: We can do better by naniwaduni on Monday June 21, 2021 @11:24PM (#27587607)
> 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)?

Re:Git undo: We can do better by cerved on Tuesday June 22, 2021 @03:22AM (#27588913)
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