• AnAmericanPotato@programming.dev
    link
    fedilink
    English
    arrow-up
    77
    arrow-down
    1
    ·
    5 hours ago

    I feel bad for this kid. That really is a bad warning dialog. Nowhere does it say it’s going to delete files. Anyone who thinks that’s good design needs a break.

    Half the replies are basically “This should be obvious if your past five years of life experience is similar to mine, and if it isn’t then get fucked.” Just adding insult to injury.

    • Omega_Jimes@lemmy.ca
      link
      fedilink
      arrow-up
      34
      arrow-down
      2
      ·
      4 hours ago

      I’m not great at English, but “discard all changes” shouldn’t ever mean “Delete”.

      • Michal@programming.dev
        link
        fedilink
        arrow-up
        24
        arrow-down
        5
        ·
        3 hours ago

        In the context of version control it does. Discarding a change that creates a file means deleting the file.

        • thebestaquaman@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          1 hour ago

          If you have set up your staging area for a commit you may want to discard (unstage) changes from the staging area, as opposed to discarding changes in the working directory.

          Of course, the difference between the two is obvious if you’re using git CLI, but I can easily see someone using a GUI (and that maybe isn’t too familiar with git) misunderstanding “discard” as “unstage”.

          Either way, what happened here indicates that all the files were somehow added to the VC, without having been committed first, or something like that, because git will not let you discard a file that is untracked, because that wouldn’t make any sense. The fact that the GUI let this person delete a bunch of files without first committing them to the index is what makes this a terrible design choice, and also what makes the use of the word “discard” misleading.

        • Omega_Jimes@lemmy.ca
          link
          fedilink
          arrow-up
          3
          arrow-down
          1
          ·
          2 hours ago

          Ok fair enough, but I’m under the impression these files existed before the source control was implemented.

          I guess it’s all up to how the program handles existing files.

    • cocobean@bookwormstory.social
      link
      fedilink
      English
      arrow-up
      30
      ·
      5 hours ago

      Also, why not send them to the recycle bin? I never really thought about it before, but that does seem a reasonable UX improvement for this case

      • murtaza64@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        3 hours ago

        I wonder if there’s already a git extension to automatically stash the working tree on every clean/reset/checkout operation…

      • stetech@lemmy.world
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        3 hours ago

        Because “the underlying Git nukes them right away, so why shouldn’t we perma-delete the files, too?”

        Anything else’d be effort…