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:
The developer of this git implementation has poor / foolish judgement.
Shit will be buggy
Shit will be insecure
Shit will be a PITA to try to troubleshoot or fix
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.
Someone explain why git in a posix shell is awful pls I don’t get it
It’s not necessarily awful by itself (though this is not a production-ready implementation).
shitis the name of the project, Shell Git.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
While humorous, I’m asking why you wouldn’t want to. What makes it so ridiculous so I can find it funny
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:
The developer of this git implementation has poor / foolish judgement.
Shit will be buggy
Shit will be insecure
Shit will be a PITA to try to troubleshoot or fix
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.
https://github.com/djanderson/aho
I should have guessed.
Thank you 🤣