10 ms·

I fell in love with git because it's FAST. And it's fast because it's distributed.

by grabcocque 12y ago

bryanlarsen 12y ago
Have you ever used Perforce?
- jimktrains2 12y ago
  You mean that proprietary code? No, I avoid non F/OSS at all costs.
  - politician 12y ago
    Wherein it is pointed out that Hacker News is proprietary software.
    - jcl 12y ago
      Really? https://github.com/wting/hackernews https://github.com/wting/hackernews
      - squeaky-clean 12y ago
        Where is the license file? Just because the code can be viewed does not make it legal to use or that it is "free" or "open source".
        vonmoltke 12y ago
        https://github.com/wting/hackernews/blob/master/copyright https://github.com/wting/hackernews/blob/master/copyright
    - jimktrains2 12y ago
      Hacker News is a website (so even with their code being open-sourced, I cannot verify what exactly they're running anyway), not software I'm running (JS aside). The firmware on the routers between me and the server are proprietary, and there is nothing I can do about that. I can choose not to run proprietary software without having to not use the web.
      - CHY872 12y ago
        You sure about that? Your system will be full of proprietary firmwares, drivers, etc.
        jimktrains2 12y ago
        I avoid it as much as I possibly can. I don't know what more to tell you. I never said I'm proprietary code-free, but just that I avoid it at all costs. Hell, I've recently been forced to install proprietary code to work with government generated data. Such a mess.
- wtetzner 12y ago
  I have, and at least at my work, it's terrible. Sometimes it gets to the point where my submit requests time out several tries in a row. Yes, I'm sure it's because the people maintaining the server aren't doing it properly, but that's sort of the point. With git, you don't have to worry about it.
  - Xylakant 12y ago
    > With git, you don't have to worry about it. Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly.
    - icefox 12y ago
      But at least you can run git log and not have to wait minutes.
      - Xylakant 12y ago
        True. You are spared some of the pain, but not all of it.
      - konstruktor 12y ago
        Ironically, Perforce doesn't even have proper search in commit history when it's working as designed. No need for the server to break...
    - deathanatos 12y ago
      > Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly. But I can't code a better sysadmin into either git or Perforce. A badly managed Perforce server will have the same issues. (Unless, of course, you have an argument that Perforce under bad management somehow performs better than git under similar conditions.) With git, however, I can still commit, and I can still push and pull changes from other people using side channels such as email. I can, for the most part, keep working. Is it more difficult? Of course. But in the particular scenario, git outperforms Perforce, in my opinion. (But this is not the primary reason I use git; at work, we use GitHub and git in very much a centralized manner. GitHub has its outages, and they're annoying. But not work-ending.)
- gumby 12y ago
  Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce. There are cases when P4 is the only choice (large binaries come to mind, and really really big code bases) but it's the kind of thing you shift to because you have to, not because you want to.
  - konstruktor 12y ago
    I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't. When looking at an actual example of the latter [1], you will see that they are heavily optimizing against contention on the central database by limiting the size of database operations. If you want to do something that would require a longer database query: Enjoy your client side error message about implementation details you never wanted to know about. [1] http://research.google.com/pubs/pub39983.html http://research.google.com/pubs/pub39983.html
    - gumby 12y ago
      > I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't. Unfortunately I did not mean to. I would agree with you that binaries are the 95% use case for P4. I think most developers typically wouldn't want to check many or any binaries in (maybe the odd icon or other small, slowly-changing asset, in which case git is adequate), but game developers and people with other binary stuff (e.g. circuit designs) will have large, changing binaries. However really big (GB-scale) repos can be painful in git. This is why google gritted their teeth and used P4 until they outgrew it too. That's what I meant by "really really big" -- something of the scale that most of us will (hopefully) never see.
  - craigching 12y ago
    > Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce. Agreed. I use git-p4 for interacting with p4 servers here at work. I love that I can create my commits and make them as granular as I want without having to interact with the server until I'm ready to submit my commits. Using git-p4 means I don't have to 'p4 edit' my files before I edit them (which really sucks when the p4 server isn't available for any reason), I can simply put off any version control workflows until I'm done with my changes (and slice and dice the changes the way I want with interactive rebase). Thinking of all the little interactions I do with git which a) aren't possible with p4 or if they were b) would involve talking to the server every step of the way makes me cringe. But then out of necessity, p4 developers probably aren't creating such fine-grained commits like I like to do (and indeed isn't even possible without a lot of fore-planning with p4), so they wouldn't notice the speed impact.
- sergiotapia 12y ago
  I quit my job because we were stuck using Perforce - how's that? :P
  - craigching 12y ago
    Try the git-p4 contrib. It has its issues, but it's not bad if you're forced to use p4.
    - Crito 12y ago
      I'll second this. git-p4 kept me sane through several years of working in a very large perforce shop.
- konstruktor 12y ago
  Perforce is not fast, it cheats: You tell the server in advance what you are doing, so that the submit is fast. This comes at a tremendous price: Your editor/IDE has to have a perforce plugin to do what should be the VCS' job (tell perforce what is happening in your workspace), and the connection to the server has to be reliable and low latency, lest you want to spend seconds every time you make an edit in a file that has not been checked out already. In practice, this model is a constant source of frustration, and everything Perforce has done in the last few years seems to be workarounds for this broken architecture.
- Crito 12y ago
  Perforce sucks. From a UX perspective, it really is rotten. Furthermore, contrary to popular belief, it scales poorly. Perforce scales provided you can continue to throw money and hardware at the machine your repo is on. After a while, for large software companies, that is no longer feasible. You have to split off into multiple perforce repos, at which point you abandon the benefits of a monolithic repo. I have seen a very large software company abandon perforce for git for this reason. You can't push a single git repo as far as you can push a single perforce repo, but you can push a fleet of git repos way farther than you can push a single perforce repo, and a fleet of perforce repos is something you really don't want to deal with.
- kyrra 12y ago
  For those wondering, Perforce just announced their own DVCS implementation[0][1]. [0] http://www.perforce.com/blog/150303/introducing-helix http://www.perforce.com/blog/150303/introducing-helix [1] http://www.perforce.com/helix http://www.perforce.com/helix
- eitland 12y ago
  I have used it for some full moons. I didn't like it. This was before I learned about DVCS, so my only real reference was SVN, but for what I did (medium-size business apps, a few years of history) I can't say it felt faster than SVN. OTOH Perforce had some serious downsides like * immature eclipse plugin (would crash eclipse more than once a week, forcing a full reset every.single.time) * no Netbeans plugin (back then) * the whole idea of having to decide in advance, -while in the office or otherwise connected, which files you needed to modify and therefore "check out" - * which brings me to the next problem: by default only one person can work at a file at the same time. YMMW, I see some people liking Perforce, OTOH I see people using Macs for coding as well. (That last part is tongue-in-cheek, yes, I really wish I liked Macs and I recommend everyone to consider them.)

I fell in love with git because it's FAST. And it's fast because it's distributed.

bryanlarsen 12y ago

Have you ever used Perforce?

jimktrains2 12y ago
You mean that proprietary code? No, I avoid non F/OSS at all costs.
- politician 12y ago
  Wherein it is pointed out that Hacker News is proprietary software.
  - jcl 12y ago
    Really? https://github.com/wting/hackernews https://github.com/wting/hackernews
    - squeaky-clean 12y ago
      Where is the license file? Just because the code can be viewed does not make it legal to use or that it is "free" or "open source".
      - vonmoltke 12y ago
        https://github.com/wting/hackernews/blob/master/copyright https://github.com/wting/hackernews/blob/master/copyright
  - jimktrains2 12y ago
    Hacker News is a website (so even with their code being open-sourced, I cannot verify what exactly they're running anyway), not software I'm running (JS aside). The firmware on the routers between me and the server are proprietary, and there is nothing I can do about that. I can choose not to run proprietary software without having to not use the web.
    - CHY872 12y ago
      You sure about that? Your system will be full of proprietary firmwares, drivers, etc.
      - jimktrains2 12y ago
        I avoid it as much as I possibly can. I don't know what more to tell you. I never said I'm proprietary code-free, but just that I avoid it at all costs. Hell, I've recently been forced to install proprietary code to work with government generated data. Such a mess.
wtetzner 12y ago
I have, and at least at my work, it's terrible. Sometimes it gets to the point where my submit requests time out several tries in a row. Yes, I'm sure it's because the people maintaining the server aren't doing it properly, but that's sort of the point. With git, you don't have to worry about it.
- Xylakant 12y ago
  > With git, you don't have to worry about it. Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly.
  - icefox 12y ago
    But at least you can run git log and not have to wait minutes.
    - Xylakant 12y ago
      True. You are spared some of the pain, but not all of it.
    - konstruktor 12y ago
      Ironically, Perforce doesn't even have proper search in commit history when it's working as designed. No need for the server to break...
  - deathanatos 12y ago
    > Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly. But I can't code a better sysadmin into either git or Perforce. A badly managed Perforce server will have the same issues. (Unless, of course, you have an argument that Perforce under bad management somehow performs better than git under similar conditions.) With git, however, I can still commit, and I can still push and pull changes from other people using side channels such as email. I can, for the most part, keep working. Is it more difficult? Of course. But in the particular scenario, git outperforms Perforce, in my opinion. (But this is not the primary reason I use git; at work, we use GitHub and git in very much a centralized manner. GitHub has its outages, and they're annoying. But not work-ending.)
gumby 12y ago
Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce. There are cases when P4 is the only choice (large binaries come to mind, and really really big code bases) but it's the kind of thing you shift to because you have to, not because you want to.
- konstruktor 12y ago
  I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't. When looking at an actual example of the latter [1], you will see that they are heavily optimizing against contention on the central database by limiting the size of database operations. If you want to do something that would require a longer database query: Enjoy your client side error message about implementation details you never wanted to know about. [1] http://research.google.com/pubs/pub39983.html http://research.google.com/pubs/pub39983.html
  - gumby 12y ago
    > I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't. Unfortunately I did not mean to. I would agree with you that binaries are the 95% use case for P4. I think most developers typically wouldn't want to check many or any binaries in (maybe the odd icon or other small, slowly-changing asset, in which case git is adequate), but game developers and people with other binary stuff (e.g. circuit designs) will have large, changing binaries. However really big (GB-scale) repos can be painful in git. This is why google gritted their teeth and used P4 until they outgrew it too. That's what I meant by "really really big" -- something of the scale that most of us will (hopefully) never see.
- craigching 12y ago
  > Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce. Agreed. I use git-p4 for interacting with p4 servers here at work. I love that I can create my commits and make them as granular as I want without having to interact with the server until I'm ready to submit my commits. Using git-p4 means I don't have to 'p4 edit' my files before I edit them (which really sucks when the p4 server isn't available for any reason), I can simply put off any version control workflows until I'm done with my changes (and slice and dice the changes the way I want with interactive rebase). Thinking of all the little interactions I do with git which a) aren't possible with p4 or if they were b) would involve talking to the server every step of the way makes me cringe. But then out of necessity, p4 developers probably aren't creating such fine-grained commits like I like to do (and indeed isn't even possible without a lot of fore-planning with p4), so they wouldn't notice the speed impact.
sergiotapia 12y ago
I quit my job because we were stuck using Perforce - how's that? :P
- craigching 12y ago
  Try the git-p4 contrib. It has its issues, but it's not bad if you're forced to use p4.
  - Crito 12y ago
    I'll second this. git-p4 kept me sane through several years of working in a very large perforce shop.
konstruktor 12y ago
Perforce is not fast, it cheats: You tell the server in advance what you are doing, so that the submit is fast. This comes at a tremendous price: Your editor/IDE has to have a perforce plugin to do what should be the VCS' job (tell perforce what is happening in your workspace), and the connection to the server has to be reliable and low latency, lest you want to spend seconds every time you make an edit in a file that has not been checked out already. In practice, this model is a constant source of frustration, and everything Perforce has done in the last few years seems to be workarounds for this broken architecture.
Crito 12y ago
Perforce sucks. From a UX perspective, it really is rotten. Furthermore, contrary to popular belief, it scales poorly. Perforce scales provided you can continue to throw money and hardware at the machine your repo is on. After a while, for large software companies, that is no longer feasible. You have to split off into multiple perforce repos, at which point you abandon the benefits of a monolithic repo. I have seen a very large software company abandon perforce for git for this reason. You can't push a single git repo as far as you can push a single perforce repo, but you can push a fleet of git repos way farther than you can push a single perforce repo, and a fleet of perforce repos is something you really don't want to deal with.
kyrra 12y ago
For those wondering, Perforce just announced their own DVCS implementation[0][1]. [0] http://www.perforce.com/blog/150303/introducing-helix http://www.perforce.com/blog/150303/introducing-helix [1] http://www.perforce.com/helix http://www.perforce.com/helix
eitland 12y ago
I have used it for some full moons. I didn't like it. This was before I learned about DVCS, so my only real reference was SVN, but for what I did (medium-size business apps, a few years of history) I can't say it felt faster than SVN. OTOH Perforce had some serious downsides like * immature eclipse plugin (would crash eclipse more than once a week, forcing a full reset every.single.time) * no Netbeans plugin (back then) * the whole idea of having to decide in advance, -while in the office or otherwise connected, which files you needed to modify and therefore "check out" - * which brings me to the next problem: by default only one person can work at a file at the same time. YMMW, I see some people liking Perforce, OTOH I see people using Macs for coding as well. (That last part is tongue-in-cheek, yes, I really wish I liked Macs and I recommend everyone to consider them.)