4 ms·

Is there a historical reason why git is needlessly complex? Seeing this cheat sheet really brings it to life.

jimbob45 2y ago
Because Linus had more clout in the SE industry than anyone else and said “SVN bad” and nobody wanted to do enough research to disprove him so here we are. Merging in Subversion is a complete disaster. The Subversion people kind of acknowledge this and they have a plan and their plan sucks, too. It is incredible how stupid these people are. So for example, let's go back to one of the things where I think the designers of Subversion were complete morons. Strong opinions. That's me, right? There's a few of them in the room today, I suspect. You're stupid. (Crowd laughs) Nobody is interest in branching. Branches are completely useless unless you merge them. https://sandeep.ramgolam.com/blog/linus-torvalds-talks-about-git-at-google#genuine https://sandeep.ramgolam.com/blog/linus-torvalds-talks-about...
fragmede 2y ago
It's not needlessly complex. The workflow it was created to support is inordinately complex, and the target market for that is highly technical, so its complexity was not the issue. Kernel developers needed to communicate to other kernel developers in a decentralized manner, and needed to work on top of each other. How do you work on a project where there are 15,000 people writing code? Git was created for this purpose. It's as complex as it needs to be to support the workflows it was designed to be. A dumber tool would be easy to create, but then it would not be able to support more complex workflows like linux kernel development. So it's not needlessly complex, though it is more complex than it needs to be for simple use cases. For those needing a less complicated frontend, there's a large number of them to make it easier to interact with git. For people that aren't full-time software developers, I don't recommend using git directly. However for those that are, it's worth taking the time to understand the underlying concepts so git becomes something you understand because once you do, it's quite elegant for what it does. I'm not going to gatekeep being a software developer on whether or not you know git, but if figuring out for yourself how such a fundamental system works doesn't give you a release of dopamine, this might not be your kind of thing. Which is totally fine. There are tons of things that are and aren't my thing. I recommend https://learngitbranching.js.org https://learngitbranching.js.org for learning how to navigate around git. but of course, https://xkcd.com/1597/ https://xkcd.com/1597/ applies as well.
- Zambyte 2y ago
  After learning Jujutsu, I realized this is really wrong. The underlying data structures and operations are great, and they serve their purposes really well (such as supporting 10k+ people collaborating like you mentioned). They are what makes git great. The git command line interface is a needlessly complex abstraction on top of them that tries to encourage certain behaviors, but does a really bad job at it.
  - vrinsd 2y ago
    100% agree. The fact there are 5 different ways to do the same thing is BAD, not good. Have one well defined, documented clear way to solve a problem.
    - fragmede 2y ago
      There are 3 different ways I could get to the store, I could walk or drive or bicycle. There are also 3 different paths I can take. I could go down road A, sidestreet B, or alleyway C. I know you'd rather one big button to press that just says "do it" on it, but in order to perform complex actions on complex objects, there are going to be multiple ways to accomplish the same thing.
      - ladzoppelin 2y ago
        But what if one of the ways to the store is dangerous once in a while but usually safe and always just as fast as the other 2 ways to the store.. Laziness has nothing to with the posters question. There is nothing wrong with Git , I just don't agree with the comparison.
        fragmede 2y ago
        But if the dangerous route takes only 15 minutes, and the safe ones take an hour, why shouldn't I, being fully aware of the risks, have the option to take it when I want to? I don't know where I called anyone lazy.
wsc981 2y ago
I think most of the time you’d be ok just knowing a couple of git commands (log, add, commit, pull, push, ..?). And of course there’s also GUI tools. I don’t think git is that complex for most workflows to be honest. But there is a lot of power that is available if the need arises.
vrinsd 2y ago
Yes. Because git was created by Linus Torvalds specifically to enable and advance Linux kernel development. The fact it has become so widly adopted is a "happy accident" (or misery). Github I think has been widely credited with making git so common place ("free git hosting") but I don't think git is the "ideal" revision control system for many projects. Because it was made for Linus for Linus/Linux, this is why the terminology and sometimes workflow is backwards from every other "normal" version control system. A "Pull Request" (PR) is named that because for Linux development Linus/maintainers would PULL changes into Linux kernel tree. In almost every other version control system it's called a Merge Request which logically makes MUCH more sense because you are merging a change (where ever it came from) into a tree. Git was (still?) the only open-source distributed version control system that could handle enormous code bases with good speed which means it gained a lot of inertia at big companies as well. I vastly prefer and use Mercurial for personal projects but if you have tried to use Hg on huge code bases (I've tried on Android AOSP) it really chokes. Mercurial got the "user interface" and command-set right and has some nifty features (being able to launch a web server on the fly to get a tree view of your changes) but being written in Python, performance and scalability aren't ideal.
- 8n4vidtmkvmk 2y ago
  There's a C version of hg, and more recently a rust version. I can't say how much faster they are though
  - wakawaka28 2y ago
    I don't think those other implementations were ever finished.
- wakawaka28 2y ago
  > Mercurial got the "user interface" and command-set right and has some nifty features (being able to launch a web server on the fly to get a tree view of your changes) but being written in Python, performance and scalability aren't ideal. I used to think Mercurial had a better UI but I changed my mind after taking the time to understand Git. Mercurial does have nifty features but Git's way of working isn't hard or especially counterintuitive. You must learn the terminology to properly understand it, but after that it's smooth sailing. Git actually has fewer moving parts than Mercurial, as there are less extraneous features. Instead of 3 or more categories of "branch-like" graph structures like Mercurial, you get branches as refs in Git. Every named leaf in the commit graph is a branch or a tag, and those have simple properties. There are surely git plugins to add more metadata but you don't really need that. Git too has a web interface by default: https://git-scm.com/docs/gitweb https://git-scm.com/docs/gitweb Of course there are many Github-like solutions specifically catered to hosting repos and entire project workflows with Git too.
sam_bristow 2y ago
Some of the complexity comes from the fact that in earlier versions it was reasonably expensive to add new subcommands. As a result more functionality got added to existing subcommands like git checkout. This made the UX more confusing. In newer versions of git the cost of adding new subcommands is reduced and they've started adding more specific commands like git switch.
- tambourine_man 2y ago
  Why was that?
- marssaxman 2y ago
  The addition of `switch` and `restore` has probably reduced my daily cursing-at-git rate by half.
tasuki 2y ago
Git is not complex. Its UI is! Git is very simple. It is built on just four concepts: blobs, trees, commits, refs.
eviks 2y ago
Because good UI design requires a different skill and takes extra effort to achieve, so it's most often just ignored

Because Linus had more clout in the SE industry than anyone else and said “SVN bad” and nobody wanted to do enough research to disprove him so here we are. Merging in Subversion is a complete disaster. The Subversion people kind of acknowledge this and they have a plan and their plan sucks, too. It is incredible how stupid these people are. So for example, let's go back to one of the things where I think the designers of Subversion were complete morons. Strong opinions. That's me, right? There's a few of them in the room today, I suspect. You're stupid. (Crowd laughs) Nobody is interest in branching. Branches are completely useless unless you merge them. https://sandeep.ramgolam.com/blog/linus-torvalds-talks-about-git-at-google#genuine https://sandeep.ramgolam.com/blog/linus-torvalds-talks-about...

fragmede 2y ago

It's not needlessly complex. The workflow it was created to support is inordinately complex, and the target market for that is highly technical, so its complexity was not the issue. Kernel developers needed to communicate to other kernel developers in a decentralized manner, and needed to work on top of each other. How do you work on a project where there are 15,000 people writing code? Git was created for this purpose. It's as complex as it needs to be to support the workflows it was designed to be. A dumber tool would be easy to create, but then it would not be able to support more complex workflows like linux kernel development. So it's not needlessly complex, though it is more complex than it needs to be for simple use cases. For those needing a less complicated frontend, there's a large number of them to make it easier to interact with git. For people that aren't full-time software developers, I don't recommend using git directly. However for those that are, it's worth taking the time to understand the underlying concepts so git becomes something you understand because once you do, it's quite elegant for what it does. I'm not going to gatekeep being a software developer on whether or not you know git, but if figuring out for yourself how such a fundamental system works doesn't give you a release of dopamine, this might not be your kind of thing. Which is totally fine. There are tons of things that are and aren't my thing. I recommend https://learngitbranching.js.org https://learngitbranching.js.org for learning how to navigate around git. but of course, https://xkcd.com/1597/ https://xkcd.com/1597/ applies as well.

Zambyte 2y ago
After learning Jujutsu, I realized this is really wrong. The underlying data structures and operations are great, and they serve their purposes really well (such as supporting 10k+ people collaborating like you mentioned). They are what makes git great. The git command line interface is a needlessly complex abstraction on top of them that tries to encourage certain behaviors, but does a really bad job at it.
- vrinsd 2y ago
  100% agree. The fact there are 5 different ways to do the same thing is BAD, not good. Have one well defined, documented clear way to solve a problem.
  - fragmede 2y ago
    There are 3 different ways I could get to the store, I could walk or drive or bicycle. There are also 3 different paths I can take. I could go down road A, sidestreet B, or alleyway C. I know you'd rather one big button to press that just says "do it" on it, but in order to perform complex actions on complex objects, there are going to be multiple ways to accomplish the same thing.
    - ladzoppelin 2y ago
      But what if one of the ways to the store is dangerous once in a while but usually safe and always just as fast as the other 2 ways to the store.. Laziness has nothing to with the posters question. There is nothing wrong with Git , I just don't agree with the comparison.
      - fragmede 2y ago
        But if the dangerous route takes only 15 minutes, and the safe ones take an hour, why shouldn't I, being fully aware of the risks, have the option to take it when I want to? I don't know where I called anyone lazy.

wsc981 2y ago

I think most of the time you’d be ok just knowing a couple of git commands (log, add, commit, pull, push, ..?). And of course there’s also GUI tools. I don’t think git is that complex for most workflows to be honest. But there is a lot of power that is available if the need arises.

vrinsd 2y ago

Yes. Because git was created by Linus Torvalds specifically to enable and advance Linux kernel development. The fact it has become so widly adopted is a "happy accident" (or misery). Github I think has been widely credited with making git so common place ("free git hosting") but I don't think git is the "ideal" revision control system for many projects. Because it was made for Linus for Linus/Linux, this is why the terminology and sometimes workflow is backwards from every other "normal" version control system. A "Pull Request" (PR) is named that because for Linux development Linus/maintainers would PULL changes into Linux kernel tree. In almost every other version control system it's called a Merge Request which logically makes MUCH more sense because you are merging a change (where ever it came from) into a tree. Git was (still?) the only open-source distributed version control system that could handle enormous code bases with good speed which means it gained a lot of inertia at big companies as well. I vastly prefer and use Mercurial for personal projects but if you have tried to use Hg on huge code bases (I've tried on Android AOSP) it really chokes. Mercurial got the "user interface" and command-set right and has some nifty features (being able to launch a web server on the fly to get a tree view of your changes) but being written in Python, performance and scalability aren't ideal.

8n4vidtmkvmk 2y ago
There's a C version of hg, and more recently a rust version. I can't say how much faster they are though
- wakawaka28 2y ago
  I don't think those other implementations were ever finished.
wakawaka28 2y ago
> Mercurial got the "user interface" and command-set right and has some nifty features (being able to launch a web server on the fly to get a tree view of your changes) but being written in Python, performance and scalability aren't ideal. I used to think Mercurial had a better UI but I changed my mind after taking the time to understand Git. Mercurial does have nifty features but Git's way of working isn't hard or especially counterintuitive. You must learn the terminology to properly understand it, but after that it's smooth sailing. Git actually has fewer moving parts than Mercurial, as there are less extraneous features. Instead of 3 or more categories of "branch-like" graph structures like Mercurial, you get branches as refs in Git. Every named leaf in the commit graph is a branch or a tag, and those have simple properties. There are surely git plugins to add more metadata but you don't really need that. Git too has a web interface by default: https://git-scm.com/docs/gitweb https://git-scm.com/docs/gitweb Of course there are many Github-like solutions specifically catered to hosting repos and entire project workflows with Git too.

sam_bristow 2y ago

Some of the complexity comes from the fact that in earlier versions it was reasonably expensive to add new subcommands. As a result more functionality got added to existing subcommands like git checkout. This made the UX more confusing. In newer versions of git the cost of adding new subcommands is reduced and they've started adding more specific commands like git switch.

tambourine_man 2y ago
Why was that?
marssaxman 2y ago
The addition of `switch` and `restore` has probably reduced my daily cursing-at-git rate by half.

tasuki 2y ago

Git is not complex. Its UI is! Git is very simple. It is built on just four concepts: blobs, trees, commits, refs.

eviks 2y ago

Because good UI design requires a different skill and takes extra effort to achieve, so it's most often just ignored