3 ms·

I've never had to understand the internals of a web browser or text editor in order to use it; drivers ed courses don't start with a discussion of thermodynamic

I've never had to understand the internals of a web browser or text editor in order to use it; drivers ed courses don't start with a discussion of thermodynamics. Why should it be necessary for git?

JoeAltmaier 8y ago
Because every source management tool has a model, and to use it at all you need to know the model. Else you're jabbing buttons and turning dials on a complex machine and the outcome is going to be tragic.
- oblio 8y ago
  I've used SVN reasonably well without knowing its internal model. I kind of knew a bit about it, I'd never call myself an SVN expert and I still managed to do my job efficiently. Git fails majorly in this regard.
  - jstimpfle 8y ago
    git is much more powerful. It gives you control to manipulate the repository like say, a relational database. If svn is enough for you, that's fine.
    - oblio 8y ago
      > It gives you control to manipulate the repository like say, a relational database And how many people do that? Not that many. This angle is a bit like the guy who said that he doesn't want Unix file names to be UTF-8 text-only, because he crafted a sort of relational database on top of a Unix FS and by having file names be just text he couldn't do some super niche trickery. I think it was in response to this article: https://dwheeler.com/essays/fixing-unix-linux-filenames.html https://dwheeler.com/essays/fixing-unix-linux-filenames.html > If svn is enough for you, that's fine. It is, but every job these days forces you to use git. And most places I've worked at, git is used as a glorified SVN where people just have a 2-step commit to a remote server.
      - jstimpfle 8y ago
        > And how many people do that? I regularly fix my commits, (just like I edit most comments on hn within a few minutes after sending them). And sometimes I take back commits even from the server (working in small teams). Locally, I regularly switch to older commits and branches to try things out. In svn all this requires a network connection and it is quite costly. Which means you do a hell of a lot less of it. And I would assume it shows in software quality. Man, how I used to freak out regularly waiting for a stupid svn diff or svn log to finish. These operations are the bread and butter of version control, and they are instantaneous in git. Or, aren't you regularly blocked from doing quick fixes using svn for problems that you saw, but couldn't fix them because you had a different pending commit? I have that often when working with svn (admittedly I don't know svn very well, but I'm sure it is a real blocker in many situations). Situations like these are easy in git. And how idiotic, after all, is it that we have to setup a SERVER to keep a simple log of changes to a few files? I have so many small ephemeral projects that I simply put in my laptop's home directory. There is no point in maintaining server repositories for those. Git is simply a tool that lets you do that. It lets you do bookkeeping of your data. It's a tool. While svn feels like an inflexible process. (yes, svn has the file:// protocol, but you still have to setup a separate repository, right?) In a sense, git is the sqlite of version control. You are really missing out. > It is, but every job these days forces you to use git. Here in Germany, svn seems to be the norm still in the engineering domain. But I figure the situation is quite different for web shops. > And most places I've worked at, git is used as a glorified SVN where people just have a 2-step commit to a remote server. That's my experience as well. When it's about communicating changes most setups will be centralized just like a regular svn setup. It's a fine approach for small teams. But with git you still have the huge advantage of being independent of the server. And you can easily fix problems that are already committed to the server.
  - JoeAltmaier 8y ago
    Maybe because git has a different model. Learn that, the objections go away. As the OP attempts.
    - oblio 8y ago
      This logic is kind of circular. "Git sucks, the UX is atrocious, I don't want to spend half my life learning a tool that shouldn't even need that much hand holding." "Learn Git!!!"
      - delian66 8y ago
        No the logic is not circular, and the advice to learn git is a good one. It may seem paradoxical at first to you, but is true (as are many things in this profession). Another paradoxical advice like that, is to learn vim, or emacs, but I digress. Git does not suck - as any other tool it, it just has strenghts and weaknesses (for example working with very large binary assets is its main weakness). The UX of most common git CLI operations is clean actually, as they are fast, and you do not need many arcane options (although they are there, and are documented well, for people who read...). If you screw up something, you just use the reflog to fix the state of your repo in most cases. Even if you can not (or do not want to), the troubleshooting is still easy - you can always do a fresh clone from your remote repository in a new folder and copy what you want there.
        oblio 8y ago
        You're assuming that I haven't read about Git. I've read a ton about it and its internal data structures. And regarding your digression, I'm a vim user. Regarding Git, Git does suck. It does the job Linus designed it to do, but that job is not most software engineers across the world need it to do. In smaller or in corporate shops, Subversion was almost adequate and several bad implementation details, mostly related to branching, led to its demise. So that world needed Subversion++, not Git. In the FAANG world, there's basically no company that uses Git as-is. It's strength/weaknesses aka tradeoffs aren't good enough for them. Git won because tech is a popularity contest and people in our domain like to do a lot of virtue signalling ("this tool is hard to use, I use it, so I'm special/cool").
chousuke 8y ago
You don't need to understand git's internals; I for sure don't know how it does delta compression of pack files etc. to provide you with efficient storage of snapshots and whatever else it does. However, what you do need to understand is the model that git uses, which is extremely simple. Git provides you a way to store snapshots of data into an on-disk graph data structure* that you can sync to and from remote repositories. You also get refs to store symbolic references to the snapshots in the data structure, and you can sync those too. That's pretty much my mental model of git in its entirety, and it allows me to merge, branch, rebase and perform all kinds of commit surgery with ease, because I can always tell what effect an operation is going to have on my data structure (and even if I'm wrong, I can't lose data) I seriously can't see how it could get any simpler. (*) a git repository can actually contain several separate graph data structures, but that's usually not what you want...

I've never had to understand the internals of a web browser or text editor in order to use it; drivers ed courses don't start with a discussion of thermodynamics. Why should it be necessary for git?

JoeAltmaier 8y ago

Because every source management tool has a model, and to use it at all you need to know the model. Else you're jabbing buttons and turning dials on a complex machine and the outcome is going to be tragic.

oblio 8y ago
I've used SVN reasonably well without knowing its internal model. I kind of knew a bit about it, I'd never call myself an SVN expert and I still managed to do my job efficiently. Git fails majorly in this regard.
- jstimpfle 8y ago
  git is much more powerful. It gives you control to manipulate the repository like say, a relational database. If svn is enough for you, that's fine.
  - oblio 8y ago
    > It gives you control to manipulate the repository like say, a relational database And how many people do that? Not that many. This angle is a bit like the guy who said that he doesn't want Unix file names to be UTF-8 text-only, because he crafted a sort of relational database on top of a Unix FS and by having file names be just text he couldn't do some super niche trickery. I think it was in response to this article: https://dwheeler.com/essays/fixing-unix-linux-filenames.html https://dwheeler.com/essays/fixing-unix-linux-filenames.html > If svn is enough for you, that's fine. It is, but every job these days forces you to use git. And most places I've worked at, git is used as a glorified SVN where people just have a 2-step commit to a remote server.
    - jstimpfle 8y ago
      > And how many people do that? I regularly fix my commits, (just like I edit most comments on hn within a few minutes after sending them). And sometimes I take back commits even from the server (working in small teams). Locally, I regularly switch to older commits and branches to try things out. In svn all this requires a network connection and it is quite costly. Which means you do a hell of a lot less of it. And I would assume it shows in software quality. Man, how I used to freak out regularly waiting for a stupid svn diff or svn log to finish. These operations are the bread and butter of version control, and they are instantaneous in git. Or, aren't you regularly blocked from doing quick fixes using svn for problems that you saw, but couldn't fix them because you had a different pending commit? I have that often when working with svn (admittedly I don't know svn very well, but I'm sure it is a real blocker in many situations). Situations like these are easy in git. And how idiotic, after all, is it that we have to setup a SERVER to keep a simple log of changes to a few files? I have so many small ephemeral projects that I simply put in my laptop's home directory. There is no point in maintaining server repositories for those. Git is simply a tool that lets you do that. It lets you do bookkeeping of your data. It's a tool. While svn feels like an inflexible process. (yes, svn has the file:// protocol, but you still have to setup a separate repository, right?) In a sense, git is the sqlite of version control. You are really missing out. > It is, but every job these days forces you to use git. Here in Germany, svn seems to be the norm still in the engineering domain. But I figure the situation is quite different for web shops. > And most places I've worked at, git is used as a glorified SVN where people just have a 2-step commit to a remote server. That's my experience as well. When it's about communicating changes most setups will be centralized just like a regular svn setup. It's a fine approach for small teams. But with git you still have the huge advantage of being independent of the server. And you can easily fix problems that are already committed to the server.
- JoeAltmaier 8y ago
  Maybe because git has a different model. Learn that, the objections go away. As the OP attempts.
  - oblio 8y ago
    This logic is kind of circular. "Git sucks, the UX is atrocious, I don't want to spend half my life learning a tool that shouldn't even need that much hand holding." "Learn Git!!!"
    - delian66 8y ago
      No the logic is not circular, and the advice to learn git is a good one. It may seem paradoxical at first to you, but is true (as are many things in this profession). Another paradoxical advice like that, is to learn vim, or emacs, but I digress. Git does not suck - as any other tool it, it just has strenghts and weaknesses (for example working with very large binary assets is its main weakness). The UX of most common git CLI operations is clean actually, as they are fast, and you do not need many arcane options (although they are there, and are documented well, for people who read...). If you screw up something, you just use the reflog to fix the state of your repo in most cases. Even if you can not (or do not want to), the troubleshooting is still easy - you can always do a fresh clone from your remote repository in a new folder and copy what you want there.
      - oblio 8y ago
        You're assuming that I haven't read about Git. I've read a ton about it and its internal data structures. And regarding your digression, I'm a vim user. Regarding Git, Git does suck. It does the job Linus designed it to do, but that job is not most software engineers across the world need it to do. In smaller or in corporate shops, Subversion was almost adequate and several bad implementation details, mostly related to branching, led to its demise. So that world needed Subversion++, not Git. In the FAANG world, there's basically no company that uses Git as-is. It's strength/weaknesses aka tradeoffs aren't good enough for them. Git won because tech is a popularity contest and people in our domain like to do a lot of virtue signalling ("this tool is hard to use, I use it, so I'm special/cool").

chousuke 8y ago

You don't need to understand git's internals; I for sure don't know how it does delta compression of pack files etc. to provide you with efficient storage of snapshots and whatever else it does. However, what you do need to understand is the model that git uses, which is extremely simple. Git provides you a way to store snapshots of data into an on-disk graph data structure* that you can sync to and from remote repositories. You also get refs to store symbolic references to the snapshots in the data structure, and you can sync those too. That's pretty much my mental model of git in its entirety, and it allows me to merge, branch, rebase and perform all kinds of commit surgery with ease, because I can always tell what effect an operation is going to have on my data structure (and even if I'm wrong, I can't lose data) I seriously can't see how it could get any simpler. (*) a git repository can actually contain several separate graph data structures, but that's usually not what you want...