Problem is, there’s an entire generation of users that have gotten super used to “discard changes” as a means of signalling “on second thought, don’t do anything”.
That’s definitely how it is seen.
If I were to see “Discard Changes” anywhere in a dialogue, I would assume it will discard whatever changes I made in that dialogue. In this case, probably some source control related changes.
If it were to say “Warning: This will Discard ALL changes!!!”, I might do a double take, but had I never used git CLI before, I would still assume that at most it would discard “ALL” changes made in the current session.
For me personally, I would consider it more useful for it to say:
This action will delete the following files:-followed-by-a-list-of-files-that-would-be-deleted
Continue?
Which neither has to look like a warning, acting like you might be doing something you don’t want to and also is much more useful for someone like me who wants to double check what exactly I am deleting.
Also, I have used git CLI before and apart from being able to see blame in the editor itself and maybe a better representation of tree, I don’t feel the need to use any git GUI tool. Even when I tried, I realised it was slower and more finicky to use. So, it would stand to reason that it should be targetted towards people who don’t use CLI (and might have never used git CLI).
From a certain point of view - isn’t this exactly what happened here?
I often go into a Git worktree of one of my projects and mess around a bit to try something out. If I find it’s not working, I tell git to discard the changes with git checkout . and git clean -df. What I’m saying is exactly “on second thought, don’t do anything" - while what happens in practice is that Git restores all files to their HEAD status and removes all the new files that are not already in HEAD.
Of course, the difference is that I already have all the work I want to keep under source control, so these changes I’ve discarded really were that - just changes. He, on the other hand, “was just playing with the source control option” - so these “changes” he was discarding really were all his work. But Git did not know that.
This feels like when my brother backed up a file with Onedrive, then figured he could delete the original… the one that Onedrive was keeping track of.
It’s not that these aren’t confusing, but why risk your file without testing what the software will do first? Especially before hitting anything like “delete” or “discard”?
Looks like windows should come with a dictionary.
“Huh, discard, I wonder what that does. Let’s try it on all my work from the last six months”
Idiots gonna idiot…
Problem is, there’s an entire generation of users that have gotten super used to “discard changes” as a means of signalling “on second thought, don’t do anything”.
That’s definitely how it is seen.
If I were to see “Discard Changes” anywhere in a dialogue, I would assume it will discard whatever changes I made in that dialogue. In this case, probably some source control related changes. If it were to say “Warning: This will Discard ALL changes!!!”, I might do a double take, but had I never used
gitCLI before, I would still assume that at most it would discard “ALL” changes made in the current session.For me personally, I would consider it more useful for it to say:
This action will delete the following files: - followed - by - a - list - of - files - that - would - be - deleted Continue?Which neither has to look like a warning, acting like you might be doing something you don’t want to and also is much more useful for someone like me who wants to double check what exactly I am deleting.
Also, I have used
gitCLI before and apart from being able to seeblamein the editor itself and maybe a better representation oftree, I don’t feel the need to use anygitGUI tool. Even when I tried, I realised it was slower and more finicky to use. So, it would stand to reason that it should be targetted towards people who don’t use CLI (and might have never usedgitCLI).From a certain point of view - isn’t this exactly what happened here?
I often go into a Git worktree of one of my projects and mess around a bit to try something out. If I find it’s not working, I tell git to discard the changes with
git checkout .andgit clean -df. What I’m saying is exactly “on second thought, don’t do anything" - while what happens in practice is that Git restores all files to theirHEADstatus and removes all the new files that are not already inHEAD.Of course, the difference is that I already have all the work I want to keep under source control, so these changes I’ve discarded really were that - just changes. He, on the other hand, “was just playing with the source control option” - so these “changes” he was discarding really were all his work. But Git did not know that.
This feels like when my brother backed up a file with Onedrive, then figured he could delete the original… the one that Onedrive was keeping track of.
It’s not that these aren’t confusing, but why risk your file without testing what the software will do first? Especially before hitting anything like “delete” or “discard”?
See, that’s a mistake I could see myself making. I would just assume that OneDrive was making a backup, not tracking the file.