• Phoenix3875@lemmy.world
    18·
    2 hours ago

    Reminds me of a hilarious bug in early GHC: https://gitlab.haskell.org/ghc/ghc/-/issues/163

    The compiler will delete your source file if there’s any compile error. And the user complained only by sending a very polite email to report this bug. Simon Peyton Jones mentioned it in one of his talks and I still find it quite hilarious till this day.

  • DelightfullyDivisive@lemmy.worldEnglish
    125·
    2 hours ago

    I’m sure that the “three months of work” was completely shit code. Anybody who is unfamiliar with source control (or even backups!) is prone to making stupid mistakes. Republican voters are likely to have a similar experience over the next 4 years.

  • AwkwardLookMonkeyPuppet@lemmy.worldEnglish
    102·
    3 hours ago

    Why are they messing with the source control options when they’re not using source control? Perhaps learn about stuff before you start clicking buttons and performing delete operations on your super critical files?

    • JackbyDev@programming.devEnglish
      51·
      1 hour ago

      Go read the actual thread. There was a bug someone found that files you have in there that aren’t even associated with git still get deleted. I’m not entirely convinced this was the poster’s fault.

      • zalgotext@sh.itjust.works
        24·
        2 hours ago

        If you use git and understand that VSC’s source control stuff is just a thin wrapper around git, you should understand what “discard all changes” means

        • JackbyDev@programming.devEnglish
          21·
          1 hour ago

          “discard” is not a git operation. Reset and restore are, but those weren’t the words used.

          • zalgotext@sh.itjust.works
            12·
            19 minutes ago

            I’m not claiming that “discard” is a git action. I’m claiming a git user should understand what’s meant by the phrase “discard changes”. Run git status in a repo that has changes in the working directory. In the resulting output, there’s a message:

            Changes not staged for commit:
    (use "git add <file>..." to update what will be committed) 
    (use "git restore <file>..." to discard changes in working directory)
        ...

            The phrase “discard changes” is used consistently in git’s output.

      • bitwolf@sh.itjust.worksEnglish
        23·
        2 hours ago

        I just tried right now to get the exact message.

        Are you sure you want to DELETE foo?
        This is IRREVERSIBLE!
        This file will be FOREVER LOST if you proceed.

        The confirmation button even says Delete File…

        User error.

    • SPRUNT@lemmy.world
      1·
      3 hours ago

      Man who clicks confirmation for leopards to delete his work is angry and surprised when his work is deleted.

  • kamen@lemmy.world
    213·
    6 hours ago

    That has the same energy as complaining that a file manager has “Delete” in the context menu.

    • Swedneck@discuss.tchncs.de
      91·
      2 hours ago

      except that the “delete” in file managers is actually “trash” and that’s for precisely this reason. Anyone not using the trash bin for a GUI that is capable of deleting files is either incompetent or malicious.

      frankly rm should default to using the trash bin as well, for desktop-focused distros.

    • AwkwardLookMonkeyPuppet@lemmy.worldEnglish
      33·
      3 hours ago

      I clicked delete and then clicked confirm when it asked me if I’m sure I want to delete, and all my files disappeared! What the fuck?!? Fuck this fucking operating system!!!1!!1one!!!

  • AusatKeyboardPremi@lemmy.world
    341·
    7 hours ago

    I always found Git GUIs, especially the ones built into IDEs, to be more confusing and clunkier than working with Git on a terminal. It often feels like unlearning what one knows about Git, and relearning it the way that specific GUI demands.

    Heck, I am going through the aforementioned feeling as I force myself to use Magit on Emacs. It just does not feel intuitive. But I will not give up until I have made an honest and full attempt.

    The only sensible Git GUI I ever used is Sublime Merge[0], after a coworker praised it immensely. Even that is reserved for the rarest of the rare times when the changes in the workspace gets unwieldy and unruly. For every other instance: Git CLI on a terminal.

    [0] https://www.sublimemerge.com/

    E: typo, and link to mentioned GUI.

    • Traister101@lemmy.today
      3·
      2 hours ago

      JetBrains has really nice Git integration. Interactive rebaseses and merges are quite pleasant but I’m still dipping into the command line to do stuff occasionally. Most commonly a git reset HEAD~ cause I want to split a commit though I had to dig through the reflog the other day cause I suddenly realized I lost an important branch that ended up being over a hundred commits back.

    • BehindTheBarrier@programming.dev
      4·
      5 hours ago

      How do you view diffs and merges when you say you don’t use git GUIs? External tool or terminal/command line?

      I use Jetbrains IDEs and most of my life has been IDE based git interaction. And I honestly love it, easy access to see my diffs, the most common commit, push and stage(or shelve as Jetbrains does it, which is better than visual studio). Hassle free and available beats writing anything to me.

      • AusatKeyboardPremi@lemmy.world
        11·
        5 hours ago

        How do you view diffs and merges when you say you don’t use git GUIs? External tool or terminal/command line?

        Terminal.

        I use Jetbrains IDEs and most of my life has been IDE based git interaction. And I honestly love it, easy access to see my diffs, the most common commit, push and stage(or shelve as Jetbrains does it, which is better than visual studio). Hassle free and available beats writing anything to me.

        Perhaps, it is a mix of learned behaviour and cognitive fixation, as I started out my development journey predominantly using a terminal, that I cannot fathom Git GUI being hassle free.

        Nice to read a different perspective on such a fundamental thing that I take for granted while working. Thank you for sharing it.

  • مهما طال الليل@lemm.ee
    108·
    4 hours ago

    So VS Code isn’t just slow and bloated, it also deletes your files. So glad I was turned off by its excessive memory consumption and deleted it before it deleted my files.

    Edit: also why I only ever used git from the command line, I never found a git UI that is easy to understand, and never trusted them.

    • hperrin@lemmy.world
      1·
      23 minutes ago

      You think VS Code is slow and bloated? What do you use?

      Also, on several occasions I’ve had VS Code help me recover accidentally deleted files, because the editor keeps the file in memory, regardless of if it disappears on disk (like most editors).

    • auzy@lemmy.world
      7·
      2 hours ago

      It’s really not slow or bloated. There’s a reason it’s so popular (even in Linux)

      If it’s running slow, maybe it’s time to check your computer…

      I literally had to use it to load 100 git projects simultaneously recently

    • AwkwardLookMonkeyPuppet@lemmy.worldEnglish
      7·
      1 hour ago

      No it doesn’t delete your files. Hombre from the post told it to delete his files and was then shocked when it did. It even warns you that it’s about to delete your files. Then on top of that, post person wasn’t even using source control, so they can’t get their files back. Don’t mess with the source control options if you’re not using source control. Don’t just randomly click buttons without reading, if your project files are super critical. Don’t only have a single version of your entire project in a single place on one computer. This person obviously has no idea what they’re doing, which is fine, but they don’t belong anywhere near a 5000 file project.

        • AwkwardLookMonkeyPuppet@lemmy.worldEnglish
          31·
          1 hour ago

          Why? There’s a full git log of the files. It’s trivial to get them back. That brings us to the “don’t use the source control tab if you’re not using source control” point.

      • مهما طال الليل@lemm.ee
        1·
        2 hours ago

        Two things can be right at the same time. I remember when I used to run VS6, IE and WinAmp in 128MB with KBs to spare. Even today, proper VS is a much better product than VSCode while being a full fledged IDE and not just a glorified text editor.

        • auzy@lemmy.world
          2·
          2 hours ago

          Vscode is an ide

          If vs6 is so great, feel free to use it

          It’s also about productivity, Notepad uses less ram, but is not productive. This runs fine on any machine really

          And the point of ram is to be used… You can’t check the ram usage and simply assume it’s bloated, because most apps also cache too. RAM is meant to be used

  • kamen@lemmy.world
    4·
    5 hours ago

    I agree with the “learn the CLI”, but to newcomers I’ll also suggest to look at the IDE/editor’s output channel - if there’s GUI for Git, there are also most likely logs for what’s happening under the hood - even if a little noisy, it can be a good learning resource. And of course if you’re learning and unsure of what’s happening (with the CLI or through a GUI), do so in a non-destructive manner (by having proper backups).

    • JackbyDev@programming.devEnglish
      2·
      53 minutes ago

      And they were trying to correct their priorities by looking into the source control features, so I don’t see how that’s anything other than victim blaming for them not doing it sooner.

      • Reil@beehaw.orgEnglish
        3·
        2 hours ago

        Yeah, those are novice numbers. I have infinite backups of my 0 files!

      • Vanshaj@lemmy.world
        4·
        3 hours ago

        I once lost three hours of work early on during my learning, not much that I lost but it was a moment when I learnt a lesson. Never lost work after that ever.

  • Michal@programming.dev
    62·
    6 hours ago

    If the files were already staged then git should have blobs in the git folder, so they should be recoverable.

      • MajorHavoc@programming.dev
        4·
        2 hours ago

        had no business anywhere near a project that size.

        Lol. That’s a really good point, actually.

        I add version control around file number 3200…

        (I’m kidding. Writing even a couple lines without version control makes my eye twitch.)

        • AwkwardLookMonkeyPuppet@lemmy.worldEnglish
          4·
          1 hour ago

          Even back in my super noob days, I’d keep known good working versions of the files in separate folders. I basically invented my own terrible source control system before I knew anything about svn or git.

    • marcos@lemmy.world
      142·
      6 hours ago

      Looks like they weren’t staged. He clicked on the staging option, it showed it would stage thousands of files, he said “hey I should fix my .gitignore” and clicked on what looked like either a “don’t stage” or a “forget” button, and it was a “checkout --force” button.

      The most impressive thing is all the people doubling down on the idea that a “checkout --force” button in a main interaction screen is a great idea, there’s nothing wrong with the software, and the user is a moron.

      • JohnEdwa@sopuli.xyz
        4·
        5 hours ago

        “discard changes” button - the 5000 “new file created” changes, specifically.

  • merthyr1831@lemmy.mlEnglish
    33·
    3 hours ago

    This is 2000% user error lmao even tho VS Code is a pain in the ass on w*ndows

    • JackbyDev@programming.devEnglish
      2·
      59 minutes ago

      Did you actually read the thread and see the bug they found where it deleted files unassociated with git?

      • merthyr1831@lemmy.mlEnglish
        2·
        29 minutes ago

        I did but I must have misread maybe? Because what it looked like was it picked up the existing fucked up git repo but if vscode did the fucking up the less of a skill issue 😮‍💨😮‍💨😮‍💨

        • JackbyDev@programming.devEnglish
          2·
          16 minutes ago

          It was on this linked issue. They discuss the UX of it more there and I think it’s a little better. https://github.com/microsoft/vscode/issues/32459

          In particular, this comment helps explain why I think this is (was) a problem.

          As we discuss this, keep in mind that most users who hit the “omg where are all my files” issue come into following these three simple steps:

          1. Oh what is this? Yes, let’s initialize, git sounds awesome, people use it.
          2. Oh what is this? All my files appear in this list… but they didn’t before. It looks like its touching my files, I don’t like that, how to I get them out of here?
          3. Oh what is this? Discard all changes sounds a lot like what I want to do. 💀

          People don’t hit this issue because we have that action; they hit it because they want to clear that list. And they will go through great lengths to get there, even if not knowing what their doing or after warned that they are in dangerous waters.

          Coupled with the behavior of this “discard all” being git clean rather than git reset, I get the complaints.