4 ms·

What I really want from Git, is to be able to have just a single executable for distribution, like `/bin/git` or `git.exe`. Currently Git is a mishmash of C, Sh

What I really want from Git, is to be able to have just a single executable for distribution, like `/bin/git` or `git.exe`. Currently Git is a mishmash of C, Shell (yes really), Python, Perl and who knows what else. I found from my own testing that you can actually make a static native build of the core with a few tweaks, but some big chunks of the project are still in other random languages.

Already__Taken 5y ago
git is a beacon of 'do one thing well' and honestly I'm not overly impressed
makecheck 5y ago
Actually it is very reasonable to choose the right language for the job, especially for tasks that are not performance-critical. When you are writing and debugging something new, you don’t want it to take forever to get it into a correct state. When you are maintaining things, you want readable code. And in an open-source project, you might attract more maintainers if you have code that is more accessible (e.g. simple things appear as simple as they are because they’re scripts, and people familiar with those languages can help even if they are not C programmers). It is also more likely to work cross-platform. I can imagine a lot of things that would be a very simple few lines of script but a mess to write, debug and read in C code. This is especially true if you could have (say) relied on a robust, debugged Python standard library function that has existed for years but instead had to do all of that yourself in C “because the project should only be using C”?
- svnpenn 5y ago
  The Git project has had at least one full time paid employee (Junio), for over 10 years. In my mind, it's not acceptable that what I'm asking hasn't been done yet. Also, shell is about the worst possible language you could use for a large project. If you want to see for yourself, look at the code for git-bisect. Global state spread across like 5 random shell scripts.
  - deleted 5y ago
    [deleted]
  - sigjuice 5y ago
    Right, how dare that one paid employee not anticipate and address demands from 10 years in the future.
- CRConrad 5y ago
  > ...but a mess to write, debug and read in C code. This is especially true if you could have (say) relied on a robust, debugged Python standard library function that has existed for years but instead had to do all of that yourself in C... Because there are no robust, debugged standard library functions that have existed for years in C?
  - huntie 5y ago
    When did C add standard library functions for Vecs and HashMaps? You're putting words in his mouth, no one claimed C lacked "robust, debugged standard library functions". It's no secret that the C standard library lacks implementations of a variety of things that programmers use on a daily basis.
handrous 5y ago
Ah, that explains why Libgit2 is so far behind, feature-wise. It'd be so damn nice if that were Git, and the standard CLI just a thin wrapper over it.
Cogito 5y ago
Git is (has been) in the process of rewriting many shell commands etc in C. There are a few reasons for this, but part of the reason is to make Git more portable. This work is slow, and a lot of the progress seems to be driven by the Google Summer of Code program (sort of like open source interns), so I suspect it will be a while before all the shell scripts are rewritten.

Already__Taken 5y ago

git is a beacon of 'do one thing well' and honestly I'm not overly impressed

makecheck 5y ago

Actually it is very reasonable to choose the right language for the job, especially for tasks that are not performance-critical. When you are writing and debugging something new, you don’t want it to take forever to get it into a correct state. When you are maintaining things, you want readable code. And in an open-source project, you might attract more maintainers if you have code that is more accessible (e.g. simple things appear as simple as they are because they’re scripts, and people familiar with those languages can help even if they are not C programmers). It is also more likely to work cross-platform. I can imagine a lot of things that would be a very simple few lines of script but a mess to write, debug and read in C code. This is especially true if you could have (say) relied on a robust, debugged Python standard library function that has existed for years but instead had to do all of that yourself in C “because the project should only be using C”?

svnpenn 5y ago
The Git project has had at least one full time paid employee (Junio), for over 10 years. In my mind, it's not acceptable that what I'm asking hasn't been done yet. Also, shell is about the worst possible language you could use for a large project. If you want to see for yourself, look at the code for git-bisect. Global state spread across like 5 random shell scripts.
- deleted 5y ago
  [deleted]
- sigjuice 5y ago
  Right, how dare that one paid employee not anticipate and address demands from 10 years in the future.
CRConrad 5y ago
> ...but a mess to write, debug and read in C code. This is especially true if you could have (say) relied on a robust, debugged Python standard library function that has existed for years but instead had to do all of that yourself in C... Because there are no robust, debugged standard library functions that have existed for years in C?
- huntie 5y ago
  When did C add standard library functions for Vecs and HashMaps? You're putting words in his mouth, no one claimed C lacked "robust, debugged standard library functions". It's no secret that the C standard library lacks implementations of a variety of things that programmers use on a daily basis.

handrous 5y ago

Ah, that explains why Libgit2 is so far behind, feature-wise. It'd be so damn nice if that were Git, and the standard CLI just a thin wrapper over it.

Cogito 5y ago

Git is (has been) in the process of rewriting many shell commands etc in C. There are a few reasons for this, but part of the reason is to make Git more portable. This work is slow, and a lot of the progress seems to be driven by the Google Summer of Code program (sort of like open source interns), so I suspect it will be a while before all the shell scripts are rewritten.