~sircmpwn/shit - An implementation of git in (almost) pure POSIX shell - sourcehut git
git.sr.ht
    • @FooBarrington@lemmy.world
      14•4 months ago

      It’s not necessarily awful by itself (though this is not a production-ready implementation). shit is the name of the project, Shell Git.

      • @JustUseMint@lemmy.world
        10•4 months ago

        My comment was not in reference to the name.

        " Why the fuck would you use this

        Status

        Enough plumbing commands are written to make this write the initial commit with itself, which is how the initial commit was written. Huzzah.

        How to use

        Don't"

        While humorous, I’m asking why you wouldn’t want to. What makes it so ridiculous so I can find it funny

        • @Jordan_U@lemmy.ml
          8•4 months ago

          Bash scripts are rarely the best choice for large, complicated, programs or for software that requires complex data structures. (Git is very much in both categories)

          In bash there are so many ways to accidentally shoot yourself in the foot that it’s absurd. That can lead to bizarre seeming behavior, which may break your script, or even lead to a security vulnerability.

          There are things that make it a bit more manageable, like “[[]]” instead of “[]”, but a frustrating number of such things are bash specific and this is written for the subset that is POSIX shell, meaning you don’t even get those token niceties.

          Where you generally “want” to use POSIX sh is for relatively simple scripts where the same file needs to run on Linux with bash, Linux with only BusyBox sh, OSX with zfs (and an outdated version of bash which will never be updated because Apple refuses to ship any GPLv3 software in MacOS).

          This is not that, and so one would expect that:

          1. The developer of this git implementation has poor / foolish judgement.

          2. Shit will be buggy

          3. Shit will be insecure

          4. Shit will be a PITA to try to troubleshoot or fix

          5. And shit will be slow, because bash is slow and this isn’t a job that you can just hand off all of the heavy lifting to grep / sed / awk*, because the data structures don’t lend themselves to that.

          * You could write the entire program in awk, and maybe even end up with something almost as fast as a python implementation done in ⅒ the time, but that would be terrible in other ways.