▲ 865 ▼ Microsoft Please Fix (lemmy.zip) submitted 2 years ago* (last edited 2 years ago) by Maven@lemmy.zip to c/programmer_humor@programming.dev 331 comments fedilink hide all child comments The real report
[–] Havald@lemmy.world 66 points 2 years ago (1 child) Skill issue permalink fedilink source hideshow 2 child comments replies: [–] Beacon@fedia.io 22 points 2 years ago (5 children) I don't know anything about programming, i came here from /all, but it seems to me that a command that's this permanently destructive warrants a second confirmation dialog message reminding the user that the files will be permanently deleted and not undoable permalink fedilink source parent hideshow 10 child comments replies: [–] Maven@lemmy.zip [S] 59 points 2 years ago* (2 children) Here is the exact warning that a user had to click through in order to get to where they got: permalink fedilink source parent hideshow 4 child comments replies: [–] Semi_Hemi_Demigod@lemmy.world 89 points 2 years ago (1 child) That's not a very good dialog box. He didn't make any changes, so discarding them doesn't sound like a problem. There should be a notice when you enable source control that this will permanently delete all existing files with a checkbox (checked by default) that says "Add existing files to source control." permalink fedilink source parent hideshow 2 child comments replies: [–] Pyro@programming.dev 10 points 2 years ago* (last edited 2 years ago) (1 child) He wouldn't have seen the "Discard Changes" button at all if source control wasn't already setup (and detected by VSCode). No sane program will delete files when you initialize source control either. As I found later, VSCode did have weird behaviors with source control back then. My experience is more with the latest versions. permalink fedilink source parent hideshow 2 child comments replies: [–] LordPassionFruit@lemm.ee 12 points 2 years ago (1 child) My sibling ran into this issue once. I'm not sure if it's a setting or a default, but vscode would assume they were working in a blank repo until they made a commit. Sounds like this person had the project (without source control) in another IDE, tried out VSCode, and it assumed that it was all 'changes'. I don't use VSCode, do I can't say for certain, but I know my sibling lost ~4 hours of project set up for the same reason (though they immediately realized it was their fault). permalink fedilink source parent hideshow 2 child comments replies: [–] Pyro@programming.dev 8 points 2 years ago Reading your comment and #32459, I realize that VSCode source control did have some major issues back then. It looks like they have improved though, as the latest VSCode I use doesn't auto-initialize repositories anymore. permalink fedilink source parent [–] Beacon@fedia.io 6 points 2 years ago (2 children) Hm ok yeah, that seems quite scary sounding so that i would strongly hesitate before clicking on "discard ALL changes". Still, I wonder if a second confirmation dialog with more information is warranted for a command that's so destructive. permalink fedilink source parent hideshow 4 child comments replies: [–] conciselyverbose@sh.itjust.works 58 points 2 years ago (3 children) I wouldn't assume "discard changes" means "delete files that existed before the editor did". permalink fedilink source parent hideshow 6 child comments replies: [–] subignition@fedia.io 10 points 2 years ago (2 children) It's changes from the prior commit in the repository, which, if they had not committed anything prior, would have been an empty directory. This is perhaps a good lesson in teaching version control as its own concept rather than "streamlining it" by bundling it with an editor. permalink fedilink source parent hideshow 4 child comments replies: [–] conciselyverbose@sh.itjust.works 18 points 2 years ago (1 child) You shouldn't be taking ownership of files and then deleting them without communication a hell of a lot better than that. I understand what happened. I'm saying that if you're going to delete stuff that was there before the software was, your flow to adding a project should include suggesting a base level commit of everything that's there already. permalink fedilink source parent hideshow 2 child comments replies: [–] subignition@fedia.io 5 points 2 years ago (1 child) That's definitely fair, creating a repository in a non-empty directory could definitely suggest auto-committing the current state if it doesn't already. I don't use VSCode so I wouldn't know. Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. permalink fedilink source parent hideshow 2 child comments replies: [–] T156@lemmy.world 1 point 2 years ago (1 child) Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. From the git discussions around the issue, it wasn't that the files were automatically staged, but that the "discard all changes" feature invoked a git clean, and also deleted untracked files. Since OP's project wasn't tracked, it got detonated. permalink fedilink source parent hideshow 2 child comments replies: [–] WolfLink@sh.itjust.works 2 points 2 years ago Since OP's project wasn't tracked, it got detonated. This is the biggest part of the problem. Using git directly, it just ignores files that aren’t tracked. permalink fedilink source parent [–] Scubus@sh.itjust.works 0 points 2 years ago (2 children) Ok then, the changes to the repository shouldve been discarded. Anything he uploaded shouldve been deleted from the server. Why were files on his local machine deleted? permalink fedilink source parent hideshow 4 child comments replies: [–] Zagorath@aussie.zone 8 points 2 years ago The repository in Git isn't on the server, it's on your local machine. permalink fedilink source parent [–] subignition@fedia.io 3 points 2 years ago (1 child) What makes you think a server was involved here? It was a local repository, evidenced by the reporter's bewilderment that files can be deleted without going to the Recycle Bin first. Which tells us that in addition to VCS, they were unfamiliar with Windows as well. permalink fedilink source parent hideshow 2 child comments replies: [–] Scubus@sh.itjust.works 3 points 2 years ago (2 children) Admittedly i dont use source control myself as im a hobbiest, but I didnt realize that git was local. As for the recycle bin bit, yeah theyre kinda dumb. Is source control different from git? permalink fedilink source parent hideshow 4 child comments replies: [–] subignition@fedia.io 4 points 2 years ago Hobbyist myself so no worries! Git is one example of source control / version control software. You normally have your local working copy of a repository and then a remote where you push your changes when they are finished or to share them with others. permalink fedilink source parent [–] WolfLink@sh.itjust.works 2 points 2 years ago* You may be confusing git with GitHub. git is a version control tool that lets you keep and manage a history of the files you are editing GitHub is a website (not directly affiliated with the group maintaining git) that lets you upload, backup, and share your code using the format used by the git tool. source control just refers to software to manage your source code in some form. git is the most popular tool of its kind, but there are others, for example mercurial. permalink fedilink source parent [–] Pyro@programming.dev 5 points 2 years ago (1 child) It's not that. It means discard all changes made after the last change committed to this local repository. permalink fedilink source parent hideshow 2 child comments replies: [–] fahfahfahfah@lemmy.billiam.net 9 points 2 years ago In this case it seems like it also performed a git clean and deleted his untracked files too. Someone actually opened a an issue to try and prevent the behaviour in the future permalink fedilink source parent [+] mark3748@sh.itjust.works -3 points 2 years ago (2 children) [deleted] permalink fedilink source parent hideshow 4 child comments replies: [–] tyler@programming.dev 8 points 2 years ago (1 child) discarding changes does not discard uncommitted new files. The VS Code button did a git clean which is completely unexpected. Git even refers to a git clean with completely different terminology. git reset -> "Resets the index and working tree. Any changes to tracked files in the working tree since are discarded." git clean -> "Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.". This command also requires you to specify a force option to actually do something, else it quits with an error. Note that git clean never once refers to discarding anything, and git reset never refers to removing untracked files. VS Code was doing an idiotic thing. Running git reset --hard AND git clean. There is absolutely no reason to be running git clean from an UI button ever. If you want to remove a file you can explicitly remove it. Imagine that the button said "Discard all changes" and then it ran rm -rf --no-preserve-root /*. Would that make sense as a button? No. It definitely would not. permalink fedilink source parent hideshow 2 child comments replies: [–] dosuser123456@lemmy.sdf.org 2 points 2 years ago or like "unmount d:" but instead it formats d: permalink fedilink source parent [–] onlinepersona@programming.dev 7 points 2 years ago Which is exactly the situation the dude was in. As a newbie, it's an easy mistake to make. Telling somebody who doesn't know "well, would you look at that, you didn't know!" is not just unhelpful, it's useless and condescending. Anti Commercial-AI license permalink fedilink source parent [–] TeamAssimilation@infosec.pub 8 points 2 years ago I guess cancelling would go back to the "Then you want to commit all files?" dialog, which the user didn't want to, he just wanted to cancel whatever the IDE was trying to start. permalink fedilink source parent [–] ArbiterXero@lemmy.world 30 points 2 years ago (2 children) The problem is that these are “source control basics” that everyone needs to learn the hard way once it seems. Waiting 3 months in between commits however is a really bad rookie mistake because you were worried about making a commit that wasn’t perfect. permalink fedilink source parent hideshow 4 child comments replies: [–] tyler@programming.dev 7 points 2 years ago (1 child) the problem is that VS Code ran git clean if you clicked yes, which is completely idiotic behavior. No other git client, text editor, or IDE on the planet does that. permalink fedilink source parent hideshow 2 child comments replies: [–] ArbiterXero@lemmy.world 2 points 2 years ago (1 child) Either way, waiting 3 months worth of work before a commit is the big mistake here. permalink fedilink source parent hideshow 2 child comments replies: [–] tyler@programming.dev 4 points 2 years ago (1 child) I think they hadn't ever used git before, and according to at least one person in the linked issue, vs code might have auto initialized the git repository for the user. permalink fedilink source parent hideshow 2 child comments replies: [–] ArbiterXero@lemmy.world 2 points 2 years ago In fairness, ALL git terms feel backwards at first. permalink fedilink source parent [–] chunkystyles@sopuli.xyz 2 points 2 years ago (2 children) Imperfect commits never existed when you squash. permalink fedilink source parent hideshow 4 child comments replies: [–] MajorHavoc@programming.dev 3 points 2 years ago Interesting. I wouldn't know, because I code everything perfectly the first time. Disclaimer: The above flagrant lie was brought to you by my also using rebase and squash to hide all of my mistakes. permalink fedilink source parent [–] ArbiterXero@lemmy.world 3 points 2 years ago Squash ftw. Simpler clearer history. permalink fedilink source parent [–] CaptDust@sh.itjust.works 8 points 2 years ago They clicked discard changes, confirmed it, and the computer did as instructed. This operation is normally not so destructive as it only discards uncommitted changes to realign the local directory with the remote server. Unfortunately for user, it sounds like they have never committed a change, so realignment meant reverting to an empty folder. permalink fedilink source parent [–] Starbuck@lemmy.world 7 points 2 years ago (1 child) I think it’s important to know that this program is for code developers, and the issue here is with a tool called git. Git is like file saving on steroids, because on top of saving a single file, you save many changes to files in git, add a comment for why you made those changes, and share your changes across dozens of files with other developers. What this guy did was develop for many months after starting to use git, but he never actually committed the files. Then he asked for to reset everything back to the original state, something that I do multiple times a day, and it gave him a warning that original means original and you will lose everything. And he said do it anyways. permalink fedilink source parent hideshow 2 child comments replies: [–] tyler@programming.dev 4 points 2 years ago No he asked for a discard after importing the project into VS Code. discard in git terms refers to git reset, not git clean. Even if he wanted to run a git reset then this version of VS Code would have run a git clean and deleted everything. Imagine he committed all 5000 files, but had a secret.json that he hadn't committed. He didn't add it to gitignore either. Running a git reset --hard will not delete this file, but the VS Code button did exactly that because it ran a git clean. permalink fedilink source parent [–] InternetCitizen2@lemmy.world 4 points 2 years ago (1 child) Perhaps. Still I am not sure why someone who is not aware of this would be using VSC. If they are a student then what kind of project are they working on that they have so many files? permalink fedilink source parent hideshow 2 child comments replies: [–] testfactor@lemmy.world 1 point 2 years ago (1 child) I'm sure 99% of the files were node modules. The npm bloat is real. permalink fedilink source parent hideshow 2 child comments replies: [–] InternetCitizen2@lemmy.world 1 point 2 years ago That is wild. permalink fedilink source parent
[–] Beacon@fedia.io 22 points 2 years ago (5 children) I don't know anything about programming, i came here from /all, but it seems to me that a command that's this permanently destructive warrants a second confirmation dialog message reminding the user that the files will be permanently deleted and not undoable permalink fedilink source parent hideshow 10 child comments replies: [–] Maven@lemmy.zip [S] 59 points 2 years ago* (2 children) Here is the exact warning that a user had to click through in order to get to where they got: permalink fedilink source parent hideshow 4 child comments replies: [–] Semi_Hemi_Demigod@lemmy.world 89 points 2 years ago (1 child) That's not a very good dialog box. He didn't make any changes, so discarding them doesn't sound like a problem. There should be a notice when you enable source control that this will permanently delete all existing files with a checkbox (checked by default) that says "Add existing files to source control." permalink fedilink source parent hideshow 2 child comments replies: [–] Pyro@programming.dev 10 points 2 years ago* (last edited 2 years ago) (1 child) He wouldn't have seen the "Discard Changes" button at all if source control wasn't already setup (and detected by VSCode). No sane program will delete files when you initialize source control either. As I found later, VSCode did have weird behaviors with source control back then. My experience is more with the latest versions. permalink fedilink source parent hideshow 2 child comments replies: [–] LordPassionFruit@lemm.ee 12 points 2 years ago (1 child) My sibling ran into this issue once. I'm not sure if it's a setting or a default, but vscode would assume they were working in a blank repo until they made a commit. Sounds like this person had the project (without source control) in another IDE, tried out VSCode, and it assumed that it was all 'changes'. I don't use VSCode, do I can't say for certain, but I know my sibling lost ~4 hours of project set up for the same reason (though they immediately realized it was their fault). permalink fedilink source parent hideshow 2 child comments replies: [–] Pyro@programming.dev 8 points 2 years ago Reading your comment and #32459, I realize that VSCode source control did have some major issues back then. It looks like they have improved though, as the latest VSCode I use doesn't auto-initialize repositories anymore. permalink fedilink source parent [–] Beacon@fedia.io 6 points 2 years ago (2 children) Hm ok yeah, that seems quite scary sounding so that i would strongly hesitate before clicking on "discard ALL changes". Still, I wonder if a second confirmation dialog with more information is warranted for a command that's so destructive. permalink fedilink source parent hideshow 4 child comments replies: [–] conciselyverbose@sh.itjust.works 58 points 2 years ago (3 children) I wouldn't assume "discard changes" means "delete files that existed before the editor did". permalink fedilink source parent hideshow 6 child comments replies: [–] subignition@fedia.io 10 points 2 years ago (2 children) It's changes from the prior commit in the repository, which, if they had not committed anything prior, would have been an empty directory. This is perhaps a good lesson in teaching version control as its own concept rather than "streamlining it" by bundling it with an editor. permalink fedilink source parent hideshow 4 child comments replies: [–] conciselyverbose@sh.itjust.works 18 points 2 years ago (1 child) You shouldn't be taking ownership of files and then deleting them without communication a hell of a lot better than that. I understand what happened. I'm saying that if you're going to delete stuff that was there before the software was, your flow to adding a project should include suggesting a base level commit of everything that's there already. permalink fedilink source parent hideshow 2 child comments replies: [–] subignition@fedia.io 5 points 2 years ago (1 child) That's definitely fair, creating a repository in a non-empty directory could definitely suggest auto-committing the current state if it doesn't already. I don't use VSCode so I wouldn't know. Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. permalink fedilink source parent hideshow 2 child comments replies: [–] T156@lemmy.world 1 point 2 years ago (1 child) Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. From the git discussions around the issue, it wasn't that the files were automatically staged, but that the "discard all changes" feature invoked a git clean, and also deleted untracked files. Since OP's project wasn't tracked, it got detonated. permalink fedilink source parent hideshow 2 child comments replies: [–] WolfLink@sh.itjust.works 2 points 2 years ago Since OP's project wasn't tracked, it got detonated. This is the biggest part of the problem. Using git directly, it just ignores files that aren’t tracked. permalink fedilink source parent [–] Scubus@sh.itjust.works 0 points 2 years ago (2 children) Ok then, the changes to the repository shouldve been discarded. Anything he uploaded shouldve been deleted from the server. Why were files on his local machine deleted? permalink fedilink source parent hideshow 4 child comments replies: [–] Zagorath@aussie.zone 8 points 2 years ago The repository in Git isn't on the server, it's on your local machine. permalink fedilink source parent [–] subignition@fedia.io 3 points 2 years ago (1 child) What makes you think a server was involved here? It was a local repository, evidenced by the reporter's bewilderment that files can be deleted without going to the Recycle Bin first. Which tells us that in addition to VCS, they were unfamiliar with Windows as well. permalink fedilink source parent hideshow 2 child comments replies: [–] Scubus@sh.itjust.works 3 points 2 years ago (2 children) Admittedly i dont use source control myself as im a hobbiest, but I didnt realize that git was local. As for the recycle bin bit, yeah theyre kinda dumb. Is source control different from git? permalink fedilink source parent hideshow 4 child comments replies: [–] subignition@fedia.io 4 points 2 years ago Hobbyist myself so no worries! Git is one example of source control / version control software. You normally have your local working copy of a repository and then a remote where you push your changes when they are finished or to share them with others. permalink fedilink source parent [–] WolfLink@sh.itjust.works 2 points 2 years ago* You may be confusing git with GitHub. git is a version control tool that lets you keep and manage a history of the files you are editing GitHub is a website (not directly affiliated with the group maintaining git) that lets you upload, backup, and share your code using the format used by the git tool. source control just refers to software to manage your source code in some form. git is the most popular tool of its kind, but there are others, for example mercurial. permalink fedilink source parent [–] Pyro@programming.dev 5 points 2 years ago (1 child) It's not that. It means discard all changes made after the last change committed to this local repository. permalink fedilink source parent hideshow 2 child comments replies: [–] fahfahfahfah@lemmy.billiam.net 9 points 2 years ago In this case it seems like it also performed a git clean and deleted his untracked files too. Someone actually opened a an issue to try and prevent the behaviour in the future permalink fedilink source parent [+] mark3748@sh.itjust.works -3 points 2 years ago (2 children) [deleted] permalink fedilink source parent hideshow 4 child comments replies: [–] tyler@programming.dev 8 points 2 years ago (1 child) discarding changes does not discard uncommitted new files. The VS Code button did a git clean which is completely unexpected. Git even refers to a git clean with completely different terminology. git reset -> "Resets the index and working tree. Any changes to tracked files in the working tree since are discarded." git clean -> "Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.". This command also requires you to specify a force option to actually do something, else it quits with an error. Note that git clean never once refers to discarding anything, and git reset never refers to removing untracked files. VS Code was doing an idiotic thing. Running git reset --hard AND git clean. There is absolutely no reason to be running git clean from an UI button ever. If you want to remove a file you can explicitly remove it. Imagine that the button said "Discard all changes" and then it ran rm -rf --no-preserve-root /*. Would that make sense as a button? No. It definitely would not. permalink fedilink source parent hideshow 2 child comments replies: [–] dosuser123456@lemmy.sdf.org 2 points 2 years ago or like "unmount d:" but instead it formats d: permalink fedilink source parent [–] onlinepersona@programming.dev 7 points 2 years ago Which is exactly the situation the dude was in. As a newbie, it's an easy mistake to make. Telling somebody who doesn't know "well, would you look at that, you didn't know!" is not just unhelpful, it's useless and condescending. Anti Commercial-AI license permalink fedilink source parent [–] TeamAssimilation@infosec.pub 8 points 2 years ago I guess cancelling would go back to the "Then you want to commit all files?" dialog, which the user didn't want to, he just wanted to cancel whatever the IDE was trying to start. permalink fedilink source parent [–] ArbiterXero@lemmy.world 30 points 2 years ago (2 children) The problem is that these are “source control basics” that everyone needs to learn the hard way once it seems. Waiting 3 months in between commits however is a really bad rookie mistake because you were worried about making a commit that wasn’t perfect. permalink fedilink source parent hideshow 4 child comments replies: [–] tyler@programming.dev 7 points 2 years ago (1 child) the problem is that VS Code ran git clean if you clicked yes, which is completely idiotic behavior. No other git client, text editor, or IDE on the planet does that. permalink fedilink source parent hideshow 2 child comments replies: [–] ArbiterXero@lemmy.world 2 points 2 years ago (1 child) Either way, waiting 3 months worth of work before a commit is the big mistake here. permalink fedilink source parent hideshow 2 child comments replies: [–] tyler@programming.dev 4 points 2 years ago (1 child) I think they hadn't ever used git before, and according to at least one person in the linked issue, vs code might have auto initialized the git repository for the user. permalink fedilink source parent hideshow 2 child comments replies: [–] ArbiterXero@lemmy.world 2 points 2 years ago In fairness, ALL git terms feel backwards at first. permalink fedilink source parent [–] chunkystyles@sopuli.xyz 2 points 2 years ago (2 children) Imperfect commits never existed when you squash. permalink fedilink source parent hideshow 4 child comments replies: [–] MajorHavoc@programming.dev 3 points 2 years ago Interesting. I wouldn't know, because I code everything perfectly the first time. Disclaimer: The above flagrant lie was brought to you by my also using rebase and squash to hide all of my mistakes. permalink fedilink source parent [–] ArbiterXero@lemmy.world 3 points 2 years ago Squash ftw. Simpler clearer history. permalink fedilink source parent [–] CaptDust@sh.itjust.works 8 points 2 years ago They clicked discard changes, confirmed it, and the computer did as instructed. This operation is normally not so destructive as it only discards uncommitted changes to realign the local directory with the remote server. Unfortunately for user, it sounds like they have never committed a change, so realignment meant reverting to an empty folder. permalink fedilink source parent [–] Starbuck@lemmy.world 7 points 2 years ago (1 child) I think it’s important to know that this program is for code developers, and the issue here is with a tool called git. Git is like file saving on steroids, because on top of saving a single file, you save many changes to files in git, add a comment for why you made those changes, and share your changes across dozens of files with other developers. What this guy did was develop for many months after starting to use git, but he never actually committed the files. Then he asked for to reset everything back to the original state, something that I do multiple times a day, and it gave him a warning that original means original and you will lose everything. And he said do it anyways. permalink fedilink source parent hideshow 2 child comments replies: [–] tyler@programming.dev 4 points 2 years ago No he asked for a discard after importing the project into VS Code. discard in git terms refers to git reset, not git clean. Even if he wanted to run a git reset then this version of VS Code would have run a git clean and deleted everything. Imagine he committed all 5000 files, but had a secret.json that he hadn't committed. He didn't add it to gitignore either. Running a git reset --hard will not delete this file, but the VS Code button did exactly that because it ran a git clean. permalink fedilink source parent [–] InternetCitizen2@lemmy.world 4 points 2 years ago (1 child) Perhaps. Still I am not sure why someone who is not aware of this would be using VSC. If they are a student then what kind of project are they working on that they have so many files? permalink fedilink source parent hideshow 2 child comments replies: [–] testfactor@lemmy.world 1 point 2 years ago (1 child) I'm sure 99% of the files were node modules. The npm bloat is real. permalink fedilink source parent hideshow 2 child comments replies: [–] InternetCitizen2@lemmy.world 1 point 2 years ago That is wild. permalink fedilink source parent
[–] Maven@lemmy.zip [S] 59 points 2 years ago* (2 children) Here is the exact warning that a user had to click through in order to get to where they got: permalink fedilink source parent hideshow 4 child comments replies: [–] Semi_Hemi_Demigod@lemmy.world 89 points 2 years ago (1 child) That's not a very good dialog box. He didn't make any changes, so discarding them doesn't sound like a problem. There should be a notice when you enable source control that this will permanently delete all existing files with a checkbox (checked by default) that says "Add existing files to source control." permalink fedilink source parent hideshow 2 child comments replies: [–] Pyro@programming.dev 10 points 2 years ago* (last edited 2 years ago) (1 child) He wouldn't have seen the "Discard Changes" button at all if source control wasn't already setup (and detected by VSCode). No sane program will delete files when you initialize source control either. As I found later, VSCode did have weird behaviors with source control back then. My experience is more with the latest versions. permalink fedilink source parent hideshow 2 child comments replies: [–] LordPassionFruit@lemm.ee 12 points 2 years ago (1 child) My sibling ran into this issue once. I'm not sure if it's a setting or a default, but vscode would assume they were working in a blank repo until they made a commit. Sounds like this person had the project (without source control) in another IDE, tried out VSCode, and it assumed that it was all 'changes'. I don't use VSCode, do I can't say for certain, but I know my sibling lost ~4 hours of project set up for the same reason (though they immediately realized it was their fault). permalink fedilink source parent hideshow 2 child comments replies: [–] Pyro@programming.dev 8 points 2 years ago Reading your comment and #32459, I realize that VSCode source control did have some major issues back then. It looks like they have improved though, as the latest VSCode I use doesn't auto-initialize repositories anymore. permalink fedilink source parent [–] Beacon@fedia.io 6 points 2 years ago (2 children) Hm ok yeah, that seems quite scary sounding so that i would strongly hesitate before clicking on "discard ALL changes". Still, I wonder if a second confirmation dialog with more information is warranted for a command that's so destructive. permalink fedilink source parent hideshow 4 child comments replies: [–] conciselyverbose@sh.itjust.works 58 points 2 years ago (3 children) I wouldn't assume "discard changes" means "delete files that existed before the editor did". permalink fedilink source parent hideshow 6 child comments replies: [–] subignition@fedia.io 10 points 2 years ago (2 children) It's changes from the prior commit in the repository, which, if they had not committed anything prior, would have been an empty directory. This is perhaps a good lesson in teaching version control as its own concept rather than "streamlining it" by bundling it with an editor. permalink fedilink source parent hideshow 4 child comments replies: [–] conciselyverbose@sh.itjust.works 18 points 2 years ago (1 child) You shouldn't be taking ownership of files and then deleting them without communication a hell of a lot better than that. I understand what happened. I'm saying that if you're going to delete stuff that was there before the software was, your flow to adding a project should include suggesting a base level commit of everything that's there already. permalink fedilink source parent hideshow 2 child comments replies: [–] subignition@fedia.io 5 points 2 years ago (1 child) That's definitely fair, creating a repository in a non-empty directory could definitely suggest auto-committing the current state if it doesn't already. I don't use VSCode so I wouldn't know. Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. permalink fedilink source parent hideshow 2 child comments replies: [–] T156@lemmy.world 1 point 2 years ago (1 child) Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. From the git discussions around the issue, it wasn't that the files were automatically staged, but that the "discard all changes" feature invoked a git clean, and also deleted untracked files. Since OP's project wasn't tracked, it got detonated. permalink fedilink source parent hideshow 2 child comments replies: [–] WolfLink@sh.itjust.works 2 points 2 years ago Since OP's project wasn't tracked, it got detonated. This is the biggest part of the problem. Using git directly, it just ignores files that aren’t tracked. permalink fedilink source parent [–] Scubus@sh.itjust.works 0 points 2 years ago (2 children) Ok then, the changes to the repository shouldve been discarded. Anything he uploaded shouldve been deleted from the server. Why were files on his local machine deleted? permalink fedilink source parent hideshow 4 child comments replies: [–] Zagorath@aussie.zone 8 points 2 years ago The repository in Git isn't on the server, it's on your local machine. permalink fedilink source parent [–] subignition@fedia.io 3 points 2 years ago (1 child) What makes you think a server was involved here? It was a local repository, evidenced by the reporter's bewilderment that files can be deleted without going to the Recycle Bin first. Which tells us that in addition to VCS, they were unfamiliar with Windows as well. permalink fedilink source parent hideshow 2 child comments replies: [–] Scubus@sh.itjust.works 3 points 2 years ago (2 children) Admittedly i dont use source control myself as im a hobbiest, but I didnt realize that git was local. As for the recycle bin bit, yeah theyre kinda dumb. Is source control different from git? permalink fedilink source parent hideshow 4 child comments replies: [–] subignition@fedia.io 4 points 2 years ago Hobbyist myself so no worries! Git is one example of source control / version control software. You normally have your local working copy of a repository and then a remote where you push your changes when they are finished or to share them with others. permalink fedilink source parent [–] WolfLink@sh.itjust.works 2 points 2 years ago* You may be confusing git with GitHub. git is a version control tool that lets you keep and manage a history of the files you are editing GitHub is a website (not directly affiliated with the group maintaining git) that lets you upload, backup, and share your code using the format used by the git tool. source control just refers to software to manage your source code in some form. git is the most popular tool of its kind, but there are others, for example mercurial. permalink fedilink source parent [–] Pyro@programming.dev 5 points 2 years ago (1 child) It's not that. It means discard all changes made after the last change committed to this local repository. permalink fedilink source parent hideshow 2 child comments replies: [–] fahfahfahfah@lemmy.billiam.net 9 points 2 years ago In this case it seems like it also performed a git clean and deleted his untracked files too. Someone actually opened a an issue to try and prevent the behaviour in the future permalink fedilink source parent [+] mark3748@sh.itjust.works -3 points 2 years ago (2 children) [deleted] permalink fedilink source parent hideshow 4 child comments replies: [–] tyler@programming.dev 8 points 2 years ago (1 child) discarding changes does not discard uncommitted new files. The VS Code button did a git clean which is completely unexpected. Git even refers to a git clean with completely different terminology. git reset -> "Resets the index and working tree. Any changes to tracked files in the working tree since are discarded." git clean -> "Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.". This command also requires you to specify a force option to actually do something, else it quits with an error. Note that git clean never once refers to discarding anything, and git reset never refers to removing untracked files. VS Code was doing an idiotic thing. Running git reset --hard AND git clean. There is absolutely no reason to be running git clean from an UI button ever. If you want to remove a file you can explicitly remove it. Imagine that the button said "Discard all changes" and then it ran rm -rf --no-preserve-root /*. Would that make sense as a button? No. It definitely would not. permalink fedilink source parent hideshow 2 child comments replies: [–] dosuser123456@lemmy.sdf.org 2 points 2 years ago or like "unmount d:" but instead it formats d: permalink fedilink source parent [–] onlinepersona@programming.dev 7 points 2 years ago Which is exactly the situation the dude was in. As a newbie, it's an easy mistake to make. Telling somebody who doesn't know "well, would you look at that, you didn't know!" is not just unhelpful, it's useless and condescending. Anti Commercial-AI license permalink fedilink source parent [–] TeamAssimilation@infosec.pub 8 points 2 years ago I guess cancelling would go back to the "Then you want to commit all files?" dialog, which the user didn't want to, he just wanted to cancel whatever the IDE was trying to start. permalink fedilink source parent
[–] Semi_Hemi_Demigod@lemmy.world 89 points 2 years ago (1 child) That's not a very good dialog box. He didn't make any changes, so discarding them doesn't sound like a problem. There should be a notice when you enable source control that this will permanently delete all existing files with a checkbox (checked by default) that says "Add existing files to source control." permalink fedilink source parent hideshow 2 child comments replies: [–] Pyro@programming.dev 10 points 2 years ago* (last edited 2 years ago) (1 child) He wouldn't have seen the "Discard Changes" button at all if source control wasn't already setup (and detected by VSCode). No sane program will delete files when you initialize source control either. As I found later, VSCode did have weird behaviors with source control back then. My experience is more with the latest versions. permalink fedilink source parent hideshow 2 child comments replies: [–] LordPassionFruit@lemm.ee 12 points 2 years ago (1 child) My sibling ran into this issue once. I'm not sure if it's a setting or a default, but vscode would assume they were working in a blank repo until they made a commit. Sounds like this person had the project (without source control) in another IDE, tried out VSCode, and it assumed that it was all 'changes'. I don't use VSCode, do I can't say for certain, but I know my sibling lost ~4 hours of project set up for the same reason (though they immediately realized it was their fault). permalink fedilink source parent hideshow 2 child comments replies: [–] Pyro@programming.dev 8 points 2 years ago Reading your comment and #32459, I realize that VSCode source control did have some major issues back then. It looks like they have improved though, as the latest VSCode I use doesn't auto-initialize repositories anymore. permalink fedilink source parent
[–] Pyro@programming.dev 10 points 2 years ago* (last edited 2 years ago) (1 child) He wouldn't have seen the "Discard Changes" button at all if source control wasn't already setup (and detected by VSCode). No sane program will delete files when you initialize source control either. As I found later, VSCode did have weird behaviors with source control back then. My experience is more with the latest versions. permalink fedilink source parent hideshow 2 child comments replies: [–] LordPassionFruit@lemm.ee 12 points 2 years ago (1 child) My sibling ran into this issue once. I'm not sure if it's a setting or a default, but vscode would assume they were working in a blank repo until they made a commit. Sounds like this person had the project (without source control) in another IDE, tried out VSCode, and it assumed that it was all 'changes'. I don't use VSCode, do I can't say for certain, but I know my sibling lost ~4 hours of project set up for the same reason (though they immediately realized it was their fault). permalink fedilink source parent hideshow 2 child comments replies: [–] Pyro@programming.dev 8 points 2 years ago Reading your comment and #32459, I realize that VSCode source control did have some major issues back then. It looks like they have improved though, as the latest VSCode I use doesn't auto-initialize repositories anymore. permalink fedilink source parent
[–] LordPassionFruit@lemm.ee 12 points 2 years ago (1 child) My sibling ran into this issue once. I'm not sure if it's a setting or a default, but vscode would assume they were working in a blank repo until they made a commit. Sounds like this person had the project (without source control) in another IDE, tried out VSCode, and it assumed that it was all 'changes'. I don't use VSCode, do I can't say for certain, but I know my sibling lost ~4 hours of project set up for the same reason (though they immediately realized it was their fault). permalink fedilink source parent hideshow 2 child comments replies: [–] Pyro@programming.dev 8 points 2 years ago Reading your comment and #32459, I realize that VSCode source control did have some major issues back then. It looks like they have improved though, as the latest VSCode I use doesn't auto-initialize repositories anymore. permalink fedilink source parent
[–] Pyro@programming.dev 8 points 2 years ago Reading your comment and #32459, I realize that VSCode source control did have some major issues back then. It looks like they have improved though, as the latest VSCode I use doesn't auto-initialize repositories anymore. permalink fedilink source parent
[–] Beacon@fedia.io 6 points 2 years ago (2 children) Hm ok yeah, that seems quite scary sounding so that i would strongly hesitate before clicking on "discard ALL changes". Still, I wonder if a second confirmation dialog with more information is warranted for a command that's so destructive. permalink fedilink source parent hideshow 4 child comments replies: [–] conciselyverbose@sh.itjust.works 58 points 2 years ago (3 children) I wouldn't assume "discard changes" means "delete files that existed before the editor did". permalink fedilink source parent hideshow 6 child comments replies: [–] subignition@fedia.io 10 points 2 years ago (2 children) It's changes from the prior commit in the repository, which, if they had not committed anything prior, would have been an empty directory. This is perhaps a good lesson in teaching version control as its own concept rather than "streamlining it" by bundling it with an editor. permalink fedilink source parent hideshow 4 child comments replies: [–] conciselyverbose@sh.itjust.works 18 points 2 years ago (1 child) You shouldn't be taking ownership of files and then deleting them without communication a hell of a lot better than that. I understand what happened. I'm saying that if you're going to delete stuff that was there before the software was, your flow to adding a project should include suggesting a base level commit of everything that's there already. permalink fedilink source parent hideshow 2 child comments replies: [–] subignition@fedia.io 5 points 2 years ago (1 child) That's definitely fair, creating a repository in a non-empty directory could definitely suggest auto-committing the current state if it doesn't already. I don't use VSCode so I wouldn't know. Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. permalink fedilink source parent hideshow 2 child comments replies: [–] T156@lemmy.world 1 point 2 years ago (1 child) Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. From the git discussions around the issue, it wasn't that the files were automatically staged, but that the "discard all changes" feature invoked a git clean, and also deleted untracked files. Since OP's project wasn't tracked, it got detonated. permalink fedilink source parent hideshow 2 child comments replies: [–] WolfLink@sh.itjust.works 2 points 2 years ago Since OP's project wasn't tracked, it got detonated. This is the biggest part of the problem. Using git directly, it just ignores files that aren’t tracked. permalink fedilink source parent [–] Scubus@sh.itjust.works 0 points 2 years ago (2 children) Ok then, the changes to the repository shouldve been discarded. Anything he uploaded shouldve been deleted from the server. Why were files on his local machine deleted? permalink fedilink source parent hideshow 4 child comments replies: [–] Zagorath@aussie.zone 8 points 2 years ago The repository in Git isn't on the server, it's on your local machine. permalink fedilink source parent [–] subignition@fedia.io 3 points 2 years ago (1 child) What makes you think a server was involved here? It was a local repository, evidenced by the reporter's bewilderment that files can be deleted without going to the Recycle Bin first. Which tells us that in addition to VCS, they were unfamiliar with Windows as well. permalink fedilink source parent hideshow 2 child comments replies: [–] Scubus@sh.itjust.works 3 points 2 years ago (2 children) Admittedly i dont use source control myself as im a hobbiest, but I didnt realize that git was local. As for the recycle bin bit, yeah theyre kinda dumb. Is source control different from git? permalink fedilink source parent hideshow 4 child comments replies: [–] subignition@fedia.io 4 points 2 years ago Hobbyist myself so no worries! Git is one example of source control / version control software. You normally have your local working copy of a repository and then a remote where you push your changes when they are finished or to share them with others. permalink fedilink source parent [–] WolfLink@sh.itjust.works 2 points 2 years ago* You may be confusing git with GitHub. git is a version control tool that lets you keep and manage a history of the files you are editing GitHub is a website (not directly affiliated with the group maintaining git) that lets you upload, backup, and share your code using the format used by the git tool. source control just refers to software to manage your source code in some form. git is the most popular tool of its kind, but there are others, for example mercurial. permalink fedilink source parent [–] Pyro@programming.dev 5 points 2 years ago (1 child) It's not that. It means discard all changes made after the last change committed to this local repository. permalink fedilink source parent hideshow 2 child comments replies: [–] fahfahfahfah@lemmy.billiam.net 9 points 2 years ago In this case it seems like it also performed a git clean and deleted his untracked files too. Someone actually opened a an issue to try and prevent the behaviour in the future permalink fedilink source parent [+] mark3748@sh.itjust.works -3 points 2 years ago (2 children) [deleted] permalink fedilink source parent hideshow 4 child comments replies: [–] tyler@programming.dev 8 points 2 years ago (1 child) discarding changes does not discard uncommitted new files. The VS Code button did a git clean which is completely unexpected. Git even refers to a git clean with completely different terminology. git reset -> "Resets the index and working tree. Any changes to tracked files in the working tree since are discarded." git clean -> "Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.". This command also requires you to specify a force option to actually do something, else it quits with an error. Note that git clean never once refers to discarding anything, and git reset never refers to removing untracked files. VS Code was doing an idiotic thing. Running git reset --hard AND git clean. There is absolutely no reason to be running git clean from an UI button ever. If you want to remove a file you can explicitly remove it. Imagine that the button said "Discard all changes" and then it ran rm -rf --no-preserve-root /*. Would that make sense as a button? No. It definitely would not. permalink fedilink source parent hideshow 2 child comments replies: [–] dosuser123456@lemmy.sdf.org 2 points 2 years ago or like "unmount d:" but instead it formats d: permalink fedilink source parent [–] onlinepersona@programming.dev 7 points 2 years ago Which is exactly the situation the dude was in. As a newbie, it's an easy mistake to make. Telling somebody who doesn't know "well, would you look at that, you didn't know!" is not just unhelpful, it's useless and condescending. Anti Commercial-AI license permalink fedilink source parent [–] TeamAssimilation@infosec.pub 8 points 2 years ago I guess cancelling would go back to the "Then you want to commit all files?" dialog, which the user didn't want to, he just wanted to cancel whatever the IDE was trying to start. permalink fedilink source parent
[–] conciselyverbose@sh.itjust.works 58 points 2 years ago (3 children) I wouldn't assume "discard changes" means "delete files that existed before the editor did". permalink fedilink source parent hideshow 6 child comments replies: [–] subignition@fedia.io 10 points 2 years ago (2 children) It's changes from the prior commit in the repository, which, if they had not committed anything prior, would have been an empty directory. This is perhaps a good lesson in teaching version control as its own concept rather than "streamlining it" by bundling it with an editor. permalink fedilink source parent hideshow 4 child comments replies: [–] conciselyverbose@sh.itjust.works 18 points 2 years ago (1 child) You shouldn't be taking ownership of files and then deleting them without communication a hell of a lot better than that. I understand what happened. I'm saying that if you're going to delete stuff that was there before the software was, your flow to adding a project should include suggesting a base level commit of everything that's there already. permalink fedilink source parent hideshow 2 child comments replies: [–] subignition@fedia.io 5 points 2 years ago (1 child) That's definitely fair, creating a repository in a non-empty directory could definitely suggest auto-committing the current state if it doesn't already. I don't use VSCode so I wouldn't know. Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. permalink fedilink source parent hideshow 2 child comments replies: [–] T156@lemmy.world 1 point 2 years ago (1 child) Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. From the git discussions around the issue, it wasn't that the files were automatically staged, but that the "discard all changes" feature invoked a git clean, and also deleted untracked files. Since OP's project wasn't tracked, it got detonated. permalink fedilink source parent hideshow 2 child comments replies: [–] WolfLink@sh.itjust.works 2 points 2 years ago Since OP's project wasn't tracked, it got detonated. This is the biggest part of the problem. Using git directly, it just ignores files that aren’t tracked. permalink fedilink source parent [–] Scubus@sh.itjust.works 0 points 2 years ago (2 children) Ok then, the changes to the repository shouldve been discarded. Anything he uploaded shouldve been deleted from the server. Why were files on his local machine deleted? permalink fedilink source parent hideshow 4 child comments replies: [–] Zagorath@aussie.zone 8 points 2 years ago The repository in Git isn't on the server, it's on your local machine. permalink fedilink source parent [–] subignition@fedia.io 3 points 2 years ago (1 child) What makes you think a server was involved here? It was a local repository, evidenced by the reporter's bewilderment that files can be deleted without going to the Recycle Bin first. Which tells us that in addition to VCS, they were unfamiliar with Windows as well. permalink fedilink source parent hideshow 2 child comments replies: [–] Scubus@sh.itjust.works 3 points 2 years ago (2 children) Admittedly i dont use source control myself as im a hobbiest, but I didnt realize that git was local. As for the recycle bin bit, yeah theyre kinda dumb. Is source control different from git? permalink fedilink source parent hideshow 4 child comments replies: [–] subignition@fedia.io 4 points 2 years ago Hobbyist myself so no worries! Git is one example of source control / version control software. You normally have your local working copy of a repository and then a remote where you push your changes when they are finished or to share them with others. permalink fedilink source parent [–] WolfLink@sh.itjust.works 2 points 2 years ago* You may be confusing git with GitHub. git is a version control tool that lets you keep and manage a history of the files you are editing GitHub is a website (not directly affiliated with the group maintaining git) that lets you upload, backup, and share your code using the format used by the git tool. source control just refers to software to manage your source code in some form. git is the most popular tool of its kind, but there are others, for example mercurial. permalink fedilink source parent [–] Pyro@programming.dev 5 points 2 years ago (1 child) It's not that. It means discard all changes made after the last change committed to this local repository. permalink fedilink source parent hideshow 2 child comments replies: [–] fahfahfahfah@lemmy.billiam.net 9 points 2 years ago In this case it seems like it also performed a git clean and deleted his untracked files too. Someone actually opened a an issue to try and prevent the behaviour in the future permalink fedilink source parent [+] mark3748@sh.itjust.works -3 points 2 years ago (2 children) [deleted] permalink fedilink source parent hideshow 4 child comments replies: [–] tyler@programming.dev 8 points 2 years ago (1 child) discarding changes does not discard uncommitted new files. The VS Code button did a git clean which is completely unexpected. Git even refers to a git clean with completely different terminology. git reset -> "Resets the index and working tree. Any changes to tracked files in the working tree since are discarded." git clean -> "Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.". This command also requires you to specify a force option to actually do something, else it quits with an error. Note that git clean never once refers to discarding anything, and git reset never refers to removing untracked files. VS Code was doing an idiotic thing. Running git reset --hard AND git clean. There is absolutely no reason to be running git clean from an UI button ever. If you want to remove a file you can explicitly remove it. Imagine that the button said "Discard all changes" and then it ran rm -rf --no-preserve-root /*. Would that make sense as a button? No. It definitely would not. permalink fedilink source parent hideshow 2 child comments replies: [–] dosuser123456@lemmy.sdf.org 2 points 2 years ago or like "unmount d:" but instead it formats d: permalink fedilink source parent [–] onlinepersona@programming.dev 7 points 2 years ago Which is exactly the situation the dude was in. As a newbie, it's an easy mistake to make. Telling somebody who doesn't know "well, would you look at that, you didn't know!" is not just unhelpful, it's useless and condescending. Anti Commercial-AI license permalink fedilink source parent
[–] subignition@fedia.io 10 points 2 years ago (2 children) It's changes from the prior commit in the repository, which, if they had not committed anything prior, would have been an empty directory. This is perhaps a good lesson in teaching version control as its own concept rather than "streamlining it" by bundling it with an editor. permalink fedilink source parent hideshow 4 child comments replies: [–] conciselyverbose@sh.itjust.works 18 points 2 years ago (1 child) You shouldn't be taking ownership of files and then deleting them without communication a hell of a lot better than that. I understand what happened. I'm saying that if you're going to delete stuff that was there before the software was, your flow to adding a project should include suggesting a base level commit of everything that's there already. permalink fedilink source parent hideshow 2 child comments replies: [–] subignition@fedia.io 5 points 2 years ago (1 child) That's definitely fair, creating a repository in a non-empty directory could definitely suggest auto-committing the current state if it doesn't already. I don't use VSCode so I wouldn't know. Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. permalink fedilink source parent hideshow 2 child comments replies: [–] T156@lemmy.world 1 point 2 years ago (1 child) Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. From the git discussions around the issue, it wasn't that the files were automatically staged, but that the "discard all changes" feature invoked a git clean, and also deleted untracked files. Since OP's project wasn't tracked, it got detonated. permalink fedilink source parent hideshow 2 child comments replies: [–] WolfLink@sh.itjust.works 2 points 2 years ago Since OP's project wasn't tracked, it got detonated. This is the biggest part of the problem. Using git directly, it just ignores files that aren’t tracked. permalink fedilink source parent [–] Scubus@sh.itjust.works 0 points 2 years ago (2 children) Ok then, the changes to the repository shouldve been discarded. Anything he uploaded shouldve been deleted from the server. Why were files on his local machine deleted? permalink fedilink source parent hideshow 4 child comments replies: [–] Zagorath@aussie.zone 8 points 2 years ago The repository in Git isn't on the server, it's on your local machine. permalink fedilink source parent [–] subignition@fedia.io 3 points 2 years ago (1 child) What makes you think a server was involved here? It was a local repository, evidenced by the reporter's bewilderment that files can be deleted without going to the Recycle Bin first. Which tells us that in addition to VCS, they were unfamiliar with Windows as well. permalink fedilink source parent hideshow 2 child comments replies: [–] Scubus@sh.itjust.works 3 points 2 years ago (2 children) Admittedly i dont use source control myself as im a hobbiest, but I didnt realize that git was local. As for the recycle bin bit, yeah theyre kinda dumb. Is source control different from git? permalink fedilink source parent hideshow 4 child comments replies: [–] subignition@fedia.io 4 points 2 years ago Hobbyist myself so no worries! Git is one example of source control / version control software. You normally have your local working copy of a repository and then a remote where you push your changes when they are finished or to share them with others. permalink fedilink source parent [–] WolfLink@sh.itjust.works 2 points 2 years ago* You may be confusing git with GitHub. git is a version control tool that lets you keep and manage a history of the files you are editing GitHub is a website (not directly affiliated with the group maintaining git) that lets you upload, backup, and share your code using the format used by the git tool. source control just refers to software to manage your source code in some form. git is the most popular tool of its kind, but there are others, for example mercurial. permalink fedilink source parent
[–] conciselyverbose@sh.itjust.works 18 points 2 years ago (1 child) You shouldn't be taking ownership of files and then deleting them without communication a hell of a lot better than that. I understand what happened. I'm saying that if you're going to delete stuff that was there before the software was, your flow to adding a project should include suggesting a base level commit of everything that's there already. permalink fedilink source parent hideshow 2 child comments replies: [–] subignition@fedia.io 5 points 2 years ago (1 child) That's definitely fair, creating a repository in a non-empty directory could definitely suggest auto-committing the current state if it doesn't already. I don't use VSCode so I wouldn't know. Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. permalink fedilink source parent hideshow 2 child comments replies: [–] T156@lemmy.world 1 point 2 years ago (1 child) Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. From the git discussions around the issue, it wasn't that the files were automatically staged, but that the "discard all changes" feature invoked a git clean, and also deleted untracked files. Since OP's project wasn't tracked, it got detonated. permalink fedilink source parent hideshow 2 child comments replies: [–] WolfLink@sh.itjust.works 2 points 2 years ago Since OP's project wasn't tracked, it got detonated. This is the biggest part of the problem. Using git directly, it just ignores files that aren’t tracked. permalink fedilink source parent
[–] subignition@fedia.io 5 points 2 years ago (1 child) That's definitely fair, creating a repository in a non-empty directory could definitely suggest auto-committing the current state if it doesn't already. I don't use VSCode so I wouldn't know. Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. permalink fedilink source parent hideshow 2 child comments replies: [–] T156@lemmy.world 1 point 2 years ago (1 child) Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. From the git discussions around the issue, it wasn't that the files were automatically staged, but that the "discard all changes" feature invoked a git clean, and also deleted untracked files. Since OP's project wasn't tracked, it got detonated. permalink fedilink source parent hideshow 2 child comments replies: [–] WolfLink@sh.itjust.works 2 points 2 years ago Since OP's project wasn't tracked, it got detonated. This is the biggest part of the problem. Using git directly, it just ignores files that aren’t tracked. permalink fedilink source parent
[–] T156@lemmy.world 1 point 2 years ago (1 child) Although now that I think about it, that could have been the intention here but not automatic, if that's why 5k+ files were staged without the user explicitly staging them. Extra tragic if that's the case. From the git discussions around the issue, it wasn't that the files were automatically staged, but that the "discard all changes" feature invoked a git clean, and also deleted untracked files. Since OP's project wasn't tracked, it got detonated. permalink fedilink source parent hideshow 2 child comments replies: [–] WolfLink@sh.itjust.works 2 points 2 years ago Since OP's project wasn't tracked, it got detonated. This is the biggest part of the problem. Using git directly, it just ignores files that aren’t tracked. permalink fedilink source parent
[–] WolfLink@sh.itjust.works 2 points 2 years ago Since OP's project wasn't tracked, it got detonated. This is the biggest part of the problem. Using git directly, it just ignores files that aren’t tracked. permalink fedilink source parent
[–] Scubus@sh.itjust.works 0 points 2 years ago (2 children) Ok then, the changes to the repository shouldve been discarded. Anything he uploaded shouldve been deleted from the server. Why were files on his local machine deleted? permalink fedilink source parent hideshow 4 child comments replies: [–] Zagorath@aussie.zone 8 points 2 years ago The repository in Git isn't on the server, it's on your local machine. permalink fedilink source parent [–] subignition@fedia.io 3 points 2 years ago (1 child) What makes you think a server was involved here? It was a local repository, evidenced by the reporter's bewilderment that files can be deleted without going to the Recycle Bin first. Which tells us that in addition to VCS, they were unfamiliar with Windows as well. permalink fedilink source parent hideshow 2 child comments replies: [–] Scubus@sh.itjust.works 3 points 2 years ago (2 children) Admittedly i dont use source control myself as im a hobbiest, but I didnt realize that git was local. As for the recycle bin bit, yeah theyre kinda dumb. Is source control different from git? permalink fedilink source parent hideshow 4 child comments replies: [–] subignition@fedia.io 4 points 2 years ago Hobbyist myself so no worries! Git is one example of source control / version control software. You normally have your local working copy of a repository and then a remote where you push your changes when they are finished or to share them with others. permalink fedilink source parent [–] WolfLink@sh.itjust.works 2 points 2 years ago* You may be confusing git with GitHub. git is a version control tool that lets you keep and manage a history of the files you are editing GitHub is a website (not directly affiliated with the group maintaining git) that lets you upload, backup, and share your code using the format used by the git tool. source control just refers to software to manage your source code in some form. git is the most popular tool of its kind, but there are others, for example mercurial. permalink fedilink source parent
[–] Zagorath@aussie.zone 8 points 2 years ago The repository in Git isn't on the server, it's on your local machine. permalink fedilink source parent
[–] subignition@fedia.io 3 points 2 years ago (1 child) What makes you think a server was involved here? It was a local repository, evidenced by the reporter's bewilderment that files can be deleted without going to the Recycle Bin first. Which tells us that in addition to VCS, they were unfamiliar with Windows as well. permalink fedilink source parent hideshow 2 child comments replies: [–] Scubus@sh.itjust.works 3 points 2 years ago (2 children) Admittedly i dont use source control myself as im a hobbiest, but I didnt realize that git was local. As for the recycle bin bit, yeah theyre kinda dumb. Is source control different from git? permalink fedilink source parent hideshow 4 child comments replies: [–] subignition@fedia.io 4 points 2 years ago Hobbyist myself so no worries! Git is one example of source control / version control software. You normally have your local working copy of a repository and then a remote where you push your changes when they are finished or to share them with others. permalink fedilink source parent [–] WolfLink@sh.itjust.works 2 points 2 years ago* You may be confusing git with GitHub. git is a version control tool that lets you keep and manage a history of the files you are editing GitHub is a website (not directly affiliated with the group maintaining git) that lets you upload, backup, and share your code using the format used by the git tool. source control just refers to software to manage your source code in some form. git is the most popular tool of its kind, but there are others, for example mercurial. permalink fedilink source parent
[–] Scubus@sh.itjust.works 3 points 2 years ago (2 children) Admittedly i dont use source control myself as im a hobbiest, but I didnt realize that git was local. As for the recycle bin bit, yeah theyre kinda dumb. Is source control different from git? permalink fedilink source parent hideshow 4 child comments replies: [–] subignition@fedia.io 4 points 2 years ago Hobbyist myself so no worries! Git is one example of source control / version control software. You normally have your local working copy of a repository and then a remote where you push your changes when they are finished or to share them with others. permalink fedilink source parent [–] WolfLink@sh.itjust.works 2 points 2 years ago* You may be confusing git with GitHub. git is a version control tool that lets you keep and manage a history of the files you are editing GitHub is a website (not directly affiliated with the group maintaining git) that lets you upload, backup, and share your code using the format used by the git tool. source control just refers to software to manage your source code in some form. git is the most popular tool of its kind, but there are others, for example mercurial. permalink fedilink source parent
[–] subignition@fedia.io 4 points 2 years ago Hobbyist myself so no worries! Git is one example of source control / version control software. You normally have your local working copy of a repository and then a remote where you push your changes when they are finished or to share them with others. permalink fedilink source parent
[–] WolfLink@sh.itjust.works 2 points 2 years ago* You may be confusing git with GitHub. git is a version control tool that lets you keep and manage a history of the files you are editing GitHub is a website (not directly affiliated with the group maintaining git) that lets you upload, backup, and share your code using the format used by the git tool. source control just refers to software to manage your source code in some form. git is the most popular tool of its kind, but there are others, for example mercurial. permalink fedilink source parent
[–] Pyro@programming.dev 5 points 2 years ago (1 child) It's not that. It means discard all changes made after the last change committed to this local repository. permalink fedilink source parent hideshow 2 child comments replies: [–] fahfahfahfah@lemmy.billiam.net 9 points 2 years ago In this case it seems like it also performed a git clean and deleted his untracked files too. Someone actually opened a an issue to try and prevent the behaviour in the future permalink fedilink source parent
[–] fahfahfahfah@lemmy.billiam.net 9 points 2 years ago In this case it seems like it also performed a git clean and deleted his untracked files too. Someone actually opened a an issue to try and prevent the behaviour in the future permalink fedilink source parent
[+] mark3748@sh.itjust.works -3 points 2 years ago (2 children) [deleted] permalink fedilink source parent hideshow 4 child comments replies: [–] tyler@programming.dev 8 points 2 years ago (1 child) discarding changes does not discard uncommitted new files. The VS Code button did a git clean which is completely unexpected. Git even refers to a git clean with completely different terminology. git reset -> "Resets the index and working tree. Any changes to tracked files in the working tree since are discarded." git clean -> "Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.". This command also requires you to specify a force option to actually do something, else it quits with an error. Note that git clean never once refers to discarding anything, and git reset never refers to removing untracked files. VS Code was doing an idiotic thing. Running git reset --hard AND git clean. There is absolutely no reason to be running git clean from an UI button ever. If you want to remove a file you can explicitly remove it. Imagine that the button said "Discard all changes" and then it ran rm -rf --no-preserve-root /*. Would that make sense as a button? No. It definitely would not. permalink fedilink source parent hideshow 2 child comments replies: [–] dosuser123456@lemmy.sdf.org 2 points 2 years ago or like "unmount d:" but instead it formats d: permalink fedilink source parent [–] onlinepersona@programming.dev 7 points 2 years ago Which is exactly the situation the dude was in. As a newbie, it's an easy mistake to make. Telling somebody who doesn't know "well, would you look at that, you didn't know!" is not just unhelpful, it's useless and condescending. Anti Commercial-AI license permalink fedilink source parent
[–] tyler@programming.dev 8 points 2 years ago (1 child) discarding changes does not discard uncommitted new files. The VS Code button did a git clean which is completely unexpected. Git even refers to a git clean with completely different terminology. git reset -> "Resets the index and working tree. Any changes to tracked files in the working tree since are discarded." git clean -> "Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.". This command also requires you to specify a force option to actually do something, else it quits with an error. Note that git clean never once refers to discarding anything, and git reset never refers to removing untracked files. VS Code was doing an idiotic thing. Running git reset --hard AND git clean. There is absolutely no reason to be running git clean from an UI button ever. If you want to remove a file you can explicitly remove it. Imagine that the button said "Discard all changes" and then it ran rm -rf --no-preserve-root /*. Would that make sense as a button? No. It definitely would not. permalink fedilink source parent hideshow 2 child comments replies: [–] dosuser123456@lemmy.sdf.org 2 points 2 years ago or like "unmount d:" but instead it formats d: permalink fedilink source parent
[–] dosuser123456@lemmy.sdf.org 2 points 2 years ago or like "unmount d:" but instead it formats d: permalink fedilink source parent
[–] onlinepersona@programming.dev 7 points 2 years ago Which is exactly the situation the dude was in. As a newbie, it's an easy mistake to make. Telling somebody who doesn't know "well, would you look at that, you didn't know!" is not just unhelpful, it's useless and condescending. Anti Commercial-AI license permalink fedilink source parent
[–] TeamAssimilation@infosec.pub 8 points 2 years ago I guess cancelling would go back to the "Then you want to commit all files?" dialog, which the user didn't want to, he just wanted to cancel whatever the IDE was trying to start. permalink fedilink source parent
[–] ArbiterXero@lemmy.world 30 points 2 years ago (2 children) The problem is that these are “source control basics” that everyone needs to learn the hard way once it seems. Waiting 3 months in between commits however is a really bad rookie mistake because you were worried about making a commit that wasn’t perfect. permalink fedilink source parent hideshow 4 child comments replies: [–] tyler@programming.dev 7 points 2 years ago (1 child) the problem is that VS Code ran git clean if you clicked yes, which is completely idiotic behavior. No other git client, text editor, or IDE on the planet does that. permalink fedilink source parent hideshow 2 child comments replies: [–] ArbiterXero@lemmy.world 2 points 2 years ago (1 child) Either way, waiting 3 months worth of work before a commit is the big mistake here. permalink fedilink source parent hideshow 2 child comments replies: [–] tyler@programming.dev 4 points 2 years ago (1 child) I think they hadn't ever used git before, and according to at least one person in the linked issue, vs code might have auto initialized the git repository for the user. permalink fedilink source parent hideshow 2 child comments replies: [–] ArbiterXero@lemmy.world 2 points 2 years ago In fairness, ALL git terms feel backwards at first. permalink fedilink source parent [–] chunkystyles@sopuli.xyz 2 points 2 years ago (2 children) Imperfect commits never existed when you squash. permalink fedilink source parent hideshow 4 child comments replies: [–] MajorHavoc@programming.dev 3 points 2 years ago Interesting. I wouldn't know, because I code everything perfectly the first time. Disclaimer: The above flagrant lie was brought to you by my also using rebase and squash to hide all of my mistakes. permalink fedilink source parent [–] ArbiterXero@lemmy.world 3 points 2 years ago Squash ftw. Simpler clearer history. permalink fedilink source parent
[–] tyler@programming.dev 7 points 2 years ago (1 child) the problem is that VS Code ran git clean if you clicked yes, which is completely idiotic behavior. No other git client, text editor, or IDE on the planet does that. permalink fedilink source parent hideshow 2 child comments replies: [–] ArbiterXero@lemmy.world 2 points 2 years ago (1 child) Either way, waiting 3 months worth of work before a commit is the big mistake here. permalink fedilink source parent hideshow 2 child comments replies: [–] tyler@programming.dev 4 points 2 years ago (1 child) I think they hadn't ever used git before, and according to at least one person in the linked issue, vs code might have auto initialized the git repository for the user. permalink fedilink source parent hideshow 2 child comments replies: [–] ArbiterXero@lemmy.world 2 points 2 years ago In fairness, ALL git terms feel backwards at first. permalink fedilink source parent
[–] ArbiterXero@lemmy.world 2 points 2 years ago (1 child) Either way, waiting 3 months worth of work before a commit is the big mistake here. permalink fedilink source parent hideshow 2 child comments replies: [–] tyler@programming.dev 4 points 2 years ago (1 child) I think they hadn't ever used git before, and according to at least one person in the linked issue, vs code might have auto initialized the git repository for the user. permalink fedilink source parent hideshow 2 child comments replies: [–] ArbiterXero@lemmy.world 2 points 2 years ago In fairness, ALL git terms feel backwards at first. permalink fedilink source parent
[–] tyler@programming.dev 4 points 2 years ago (1 child) I think they hadn't ever used git before, and according to at least one person in the linked issue, vs code might have auto initialized the git repository for the user. permalink fedilink source parent hideshow 2 child comments replies: [–] ArbiterXero@lemmy.world 2 points 2 years ago In fairness, ALL git terms feel backwards at first. permalink fedilink source parent
[–] ArbiterXero@lemmy.world 2 points 2 years ago In fairness, ALL git terms feel backwards at first. permalink fedilink source parent
[–] chunkystyles@sopuli.xyz 2 points 2 years ago (2 children) Imperfect commits never existed when you squash. permalink fedilink source parent hideshow 4 child comments replies: [–] MajorHavoc@programming.dev 3 points 2 years ago Interesting. I wouldn't know, because I code everything perfectly the first time. Disclaimer: The above flagrant lie was brought to you by my also using rebase and squash to hide all of my mistakes. permalink fedilink source parent [–] ArbiterXero@lemmy.world 3 points 2 years ago Squash ftw. Simpler clearer history. permalink fedilink source parent
[–] MajorHavoc@programming.dev 3 points 2 years ago Interesting. I wouldn't know, because I code everything perfectly the first time. Disclaimer: The above flagrant lie was brought to you by my also using rebase and squash to hide all of my mistakes. permalink fedilink source parent
[–] ArbiterXero@lemmy.world 3 points 2 years ago Squash ftw. Simpler clearer history. permalink fedilink source parent
[–] CaptDust@sh.itjust.works 8 points 2 years ago They clicked discard changes, confirmed it, and the computer did as instructed. This operation is normally not so destructive as it only discards uncommitted changes to realign the local directory with the remote server. Unfortunately for user, it sounds like they have never committed a change, so realignment meant reverting to an empty folder. permalink fedilink source parent
[–] Starbuck@lemmy.world 7 points 2 years ago (1 child) I think it’s important to know that this program is for code developers, and the issue here is with a tool called git. Git is like file saving on steroids, because on top of saving a single file, you save many changes to files in git, add a comment for why you made those changes, and share your changes across dozens of files with other developers. What this guy did was develop for many months after starting to use git, but he never actually committed the files. Then he asked for to reset everything back to the original state, something that I do multiple times a day, and it gave him a warning that original means original and you will lose everything. And he said do it anyways. permalink fedilink source parent hideshow 2 child comments replies: [–] tyler@programming.dev 4 points 2 years ago No he asked for a discard after importing the project into VS Code. discard in git terms refers to git reset, not git clean. Even if he wanted to run a git reset then this version of VS Code would have run a git clean and deleted everything. Imagine he committed all 5000 files, but had a secret.json that he hadn't committed. He didn't add it to gitignore either. Running a git reset --hard will not delete this file, but the VS Code button did exactly that because it ran a git clean. permalink fedilink source parent
[–] tyler@programming.dev 4 points 2 years ago No he asked for a discard after importing the project into VS Code. discard in git terms refers to git reset, not git clean. Even if he wanted to run a git reset then this version of VS Code would have run a git clean and deleted everything. Imagine he committed all 5000 files, but had a secret.json that he hadn't committed. He didn't add it to gitignore either. Running a git reset --hard will not delete this file, but the VS Code button did exactly that because it ran a git clean. permalink fedilink source parent
[–] InternetCitizen2@lemmy.world 4 points 2 years ago (1 child) Perhaps. Still I am not sure why someone who is not aware of this would be using VSC. If they are a student then what kind of project are they working on that they have so many files? permalink fedilink source parent hideshow 2 child comments replies: [–] testfactor@lemmy.world 1 point 2 years ago (1 child) I'm sure 99% of the files were node modules. The npm bloat is real. permalink fedilink source parent hideshow 2 child comments replies: [–] InternetCitizen2@lemmy.world 1 point 2 years ago That is wild. permalink fedilink source parent
[–] testfactor@lemmy.world 1 point 2 years ago (1 child) I'm sure 99% of the files were node modules. The npm bloat is real. permalink fedilink source parent hideshow 2 child comments replies: [–] InternetCitizen2@lemmy.world 1 point 2 years ago That is wild. permalink fedilink source parent
