5 ms·

The Git Revolution Is Here

46 points by draegtun 14y ago

ojiikun 14y ago
It is interesting that they mention Perforce releasing a git-compatible frontend/adaptor. I've heard that at least two top-10 code shops (hint: both are in Seattle) built something like this in-house over a year ago since they were unable to switch away from P4 but wanted to placate newer devs that liked git.
- draegtun 14y ago
  The Perl source code use to be on Perforce before moving to Git a few years back. They probably could have done with this adaptor because it took some effort to get 21 years of Perl commit history over to Git! - http://www.perlfoundation.org/perl_5_development_now_on_git http://www.perlfoundation.org/perl_5_development_now_on_git extra ref: Perl5 git repo: http://perl5.git.perl.org/perl.git http://perl5.git.perl.org/perl.git | Github mirror: https://github.com/mirrors/perl https://github.com/mirrors/perl
- i386 14y ago
  Many companies I spoke to are stuck with Perforce because its the only version control system that has been proven to scale with thousands of users. Thats not to say Git can't scale but convincing enterprises that Git can scale and showing how they can do it is the next challenge for Git evangelists.
  - retube 14y ago
    Many enterprises will stick to expensive paid solutions because if anything goes wrong they need to be able to sue someone.
    - narcissus 14y ago
      And yet most of these expensive paid solutions have EULAs that strictly tell you that you're not going to get anything if you sue them anyway...
    - prawks 14y ago
      they need to be able to dial support. FTFY. Vendor apps and commercialized software aren't purchased (to my knowledge) with the intent of being able to point the finger with the buyer's lawyer. The reason large enterprises prefer Perforce/TFS/etc. is (along with their proven capability to scale) that if something goes wrong they can call the vendor for help. While you might be able to post on a usergroup and hope for a response, you can't call Linus directly. That's a big difference for the people making the decisions from a financial, architectural, and tools-planning level.
      - phaemon 14y ago
        You can buy Git support from several different vendors. Were you honestly not aware of this? Try googling for "Git support".
        elemeno 14y ago
        Which isn't quite the same as being able to get support from the company which built the software and who can push out a new release to fix the bug that you've just run into.
        phaemon 14y ago
        (is there a better way to do quotes on HN?) > Which isn't quite the same as being able to get support from the company which built the software I'm sure they'll build Git for you if you ask :) Do you think the original authors of Perforce etc. are still with the company? Are you under the impression that their current development team understand the Perforce source code far better than people providing professional Git support understand Git's? > and who can push out a new release to fix the bug that you've just run into. That's exactly what Git support can do. Why not? [edit: to clarify who "they" are]
        hanksf 14y ago
        Christopher Seiwald is still at Perforce. I would have to say: Yes, the current Perforce development team understands the Perforce source code intimately at least as well as the core developers of Git know Git, if not better. Disclaimer: I work for Perforce
  - to3m 14y ago
    I don't think git can scale, at least not currently, to the extent perforce can. There's two main problems holding it back: - Storage of database on local drive - the last time I worked with perforce, HEAD alone was 280GB... where would this fit? (there's a presentation about google's use of perforce where they say the metadata alone for their database is >1TB! - so even storing just metadata might not fly) - As number of people using database increases, chance of needing to store hand-modified binary files (Office, Photoshop, Maya/Max/XSI/etc.) increases, and advantage to storing non-modified binary files (old builds, tools, etc.) increases. (Storing things in shares on people's PCs, or having two systems, or whatever, just ain't great.) Centralized locking is pretty much essential for such files, but, being centralized, it's hard to support with a distributed system... The former problem could almost certainly be solved. The latter I'm less sure about. Partly for technical reasons, but partly because the idea that binary files shouldn't be version-controlled is, for some people (and I don't know if the git people are of this mind), a point of inviolable principle.
    - lucisferre 14y ago
      You would be surprised. Git's differential compression is pretty impressive. I worked at an SVN show where HEAD was about 270mb but when I cloned it in Git the bare repo was only 130mb. Git also let's you clone parts of the tree and sections of the history (at least when working with SVN it did).
      - plorkyeran 14y ago
        That's mostly a SVN problem; checkouts are exceptionally large due to that they have a lot of metadata and a second copy of each file for local diffing/etc. which are uncompressed. Perforce doesn't do the same thing.
      - to3m 14y ago
        You may be right. My suspicion would be that a lot of the data is not terribly compressible, and that you'd be looking at over 1TB for the repository of a decent-size project. Add one checkout of head on top; add build products to that. Build products mount up surprisingly quickly, with multiple gigabytes of objects and PDBs being common. 1+TB (and git doesn't support partial checkouts) would make it difficult for people to work off a laptop, or use a SSD. Everybody would need 2 2TB drives on the off chance that they might have to work on more than one project at once. Or you'd have to check less stuff into the git repository. I know people say disk space is cheap; I just don't think it's quite cheap enough yet to piss away to this degree. It's one thing to have a server with masses of storage, I'm just not convinced you can require every client PC to have the same. I could be wrong.
  - eob 14y ago
    Can the extensive code-review systems often layered on top of Perforce be achieved with git? As someone who has used both, the workflow features geared towards large organizations and professional-grade code processes have always struck me as a major feature of p4.
    - mullr 14y ago
      http://code.google.com/p/gerrit/ http://code.google.com/p/gerrit/
    - i386 14y ago
      Atlassian Stash was released recently with a code review process built around pull requests (For those that don't know, Stash is a Enterprise Git repository server) http://blogs.atlassian.com/2012/10/stash-13-enterprise-git-pull-request/ http://blogs.atlassian.com/2012/10/stash-13-enterprise-git-p... Disclaimer: I work for Atlassian
  - icefox 14y ago
    Having helped several large companies migrate I would agree that this is a top concern, but it can be shown that Git can handle all of the users without any problem. Common tips like: If you are using pure ssh beyond 500 users you want to move away from the stock sshd. When possible setting up git to handle fetches over smart-http can scale git significantly (I would use all available bandwidth to the box before the cpu was anywhere near to pegged). The usual server side backups, routing and distributing load to local offices are all issues that are not too difficult to deal with. Even going through a worse case situation and on purpose corrupting the git database as an exercise is worth doing with new admin's. Inside the enterprise firewall there are a number of tools such as gitolite, github enterprise, gerrit, etc out there that are available to make the users and server admin's happy. Beyond that there are presentations, books, youtube videos, wiki's etc. I found making sure there is one "local export" really helps make things go smoother and and internal chat room / mailing list for Git can't hurt too. Slowly migrating users by teachings the early adopters with git-p4 also helps to prevent the sudden switch on "Monday" that goes horribly wrong causing everyone to loose a few days. The real problem has been shops that have 400GB perforce servers and they employed absolutely no rules about where things would live on the server. This would result in Perforce clients that would cherry pick directories from all sorts of random sub directories across the Perforce server to build a product (v.s. say something simpler like projectFoo/, 3rdparty/, and binaryTools/) The worst are the exceptions in the perforce client such as the perforce client would grab the src/ directory, but exclude src/vs/ because a few years ago someone checked in a visual studio install into the src directory and somewhere someone is still using it so they can't remove/move it... Even if they stick with Perforce companies like this really should clean up their repositories, call it simple professionalism. After a repository is cleaned up (even a basic pass can make a huge deal) then using git on top of perforce or even thinking of migrating is much easier to do. Using Git inside large companies is completely doable right now. In the past when Git was younger I gave a few presentations in the Boston area (where I live) to companies that were interested in learning more. If your in the area and if you just want to pick my brain on the topic or how it might apply to your situation I am always up for grabbing lunch.
    - to3m 14y ago
      What do you do about storing binary files in git? And is git not actually bothered by having a 400GB repository? I was under the impression that sort of thing was just not its intended use.
- Jach 14y ago
  git-p4 isn't really a good tool if your Perforce repo has branches... But you can get it to do the job with enough effort, and it's probably fine as a simple front-end (I never used it as such). My experience with it consisted of migrating LucidDB from its hosted Perforce server over to GitHub last year, which involved the fun process of learning how to graft new parent-child topologies into a git repo.
fghh45sdfhr3 14y ago
I like and occasionally use Git, but I started with Mercurial and still prefer it. Can anyone tell me why/how Git allegedly become way better than Mercurial? I seem to have missed that.
- mercurial 14y ago
  I haven't used Mercurial for a while, but on the top of my head: - lightweight branches (your branch is just a different head, there is nothing permanent about it) - git rebase -i (rewrite your history) - git add --patch (add parts of a file to a commit instead of the whole file) - the philosophy of preparing the commit by putting the files or portions of files you want to commit in the staging area, as opposed to committing everything per default I know Mercurial has alternatives to most of these functionalities, through various plugins. But I can't say I found them nearly as usable as Git. And that's saying something considering Git's command line interface.
- msgilligan 14y ago
  I don't think the article says Git is way better. It says it is way more popular, which is clearly true.
positr0n 14y ago
What is the git front end to perforce they talk about? All I know about is git-p4 (open source python script, still a little buggy last time I checked) and P4-Sandbox, which is supposed to be DCVS type features implemented in perforce. A real git front end would be awesome!
- xgalvez 14y ago
  Not sure it's a front-end (looks like it's a Perforce front-end to Git), but I believe it's an interface that makes the two work together: http://www.perforce.com/git-fusion http://www.perforce.com/git-fusion
sixothree 14y ago
The fact that the project managers and office staff at my workplace are unable to / incapable of using git is a deal-breaker. Git needs serious work in this regard.
- jonpaul 14y ago
  Shameless plug: http://gitpilot.com http://gitpilot.com this is part of the problem that we are trying to solve. We would love more feedback.
  - thasmin 14y ago
    I'm not sure what gitpilot does. It's difficult to understand what's happening on the video. Two suggestions: 1. Windows client and 2. screenshots next to each of the six items on the page to demonstrate what you're explaining.
    - jonpaul 14y ago
      Thank you for your feedback. Of all of the market research that I've done so far, it seems that there still isn't a lot of Git developers on Windows. Outside of your own development, are many of your peers using Windows/Git? Excellent suggestion with the screenshots and the six items.
      - cbaleanu 14y ago
        Maybe I'm missing the point, but I'm using this http://windows.github.com/ http://windows.github.com/ and it's pretty good, specifically the shell.
- synaesthete 14y ago
  Git/most Git clients weren't designed for project managers or other document users. [shameless plug] Perforce has a new product (http://www.perforce.com/products/commons http://www.perforce.com/products/commons) that we're working on -- a client that IS designed for those folks/for document-sharing-and-versioning use cases. So if some developers are using Git, and the idea is to keep all company stuff in a clearly-shareable and accessible spot, Git + Git Fusion + p4 + Commons would do it. [Disclaimer: I work at Perforce, hence shamelessness of plug]
happypeter 14y ago
I've been a git super fun for years. But I have to say Hg is much more friendly to newbies. My reason for git's popularity is: The code is out of the hands of Linux kernel team, so you can believe that git will work well. And the fame of Linus and later github also count.
- giulianob 14y ago
  Github attracted a lot of the Ruby developers. They are extremely vocal on the web which I think is what made Github and Git so popular. I personally prefer Hg over Git as well due to friendlier syntax but Git hit it off a lot better w/ that vocal OSX community. I don't know many people who use Windows that like Git. The ports were buggy for a long time and the best visual tool, SmartGit, isn't free. Mercurial which has TortoiseHg which is excellent but I hear is painful to get running on OSX (maybe this has changed). Mercurial is fairly popular still though. I think a lot of people use it but not many popular articles get written about it the same way it does about Git.
  - happypeter 14y ago
    Yes, ROR people talked a lot, on web, that also counts.
xgalvez 14y ago
In case people are wondering what the Perforce front-end/interface to Git was, I believe it's their "Perforce Git Fusion" product: http://www.perforce.com/git-fusion http://www.perforce.com/git-fusion Webinar's next week, and I may sign up to see what this is all about. (Disclaimer: Certified Perforce Admin here, and no, I don't work for Perforce.)
drudru11 14y ago
This would be a great story about 3 years ago

46 points by draegtun 14y ago

It is interesting that they mention Perforce releasing a git-compatible frontend/adaptor. I've heard that at least two top-10 code shops (hint: both are in Seattle) built something like this in-house over a year ago since they were unable to switch away from P4 but wanted to placate newer devs that liked git.

draegtun 14y ago
The Perl source code use to be on Perforce before moving to Git a few years back. They probably could have done with this adaptor because it took some effort to get 21 years of Perl commit history over to Git! - http://www.perlfoundation.org/perl_5_development_now_on_git http://www.perlfoundation.org/perl_5_development_now_on_git extra ref: Perl5 git repo: http://perl5.git.perl.org/perl.git http://perl5.git.perl.org/perl.git | Github mirror: https://github.com/mirrors/perl https://github.com/mirrors/perl
i386 14y ago
Many companies I spoke to are stuck with Perforce because its the only version control system that has been proven to scale with thousands of users. Thats not to say Git can't scale but convincing enterprises that Git can scale and showing how they can do it is the next challenge for Git evangelists.
- retube 14y ago
  Many enterprises will stick to expensive paid solutions because if anything goes wrong they need to be able to sue someone.
  - narcissus 14y ago
    And yet most of these expensive paid solutions have EULAs that strictly tell you that you're not going to get anything if you sue them anyway...
  - prawks 14y ago
    they need to be able to dial support. FTFY. Vendor apps and commercialized software aren't purchased (to my knowledge) with the intent of being able to point the finger with the buyer's lawyer. The reason large enterprises prefer Perforce/TFS/etc. is (along with their proven capability to scale) that if something goes wrong they can call the vendor for help. While you might be able to post on a usergroup and hope for a response, you can't call Linus directly. That's a big difference for the people making the decisions from a financial, architectural, and tools-planning level.
    - phaemon 14y ago
      You can buy Git support from several different vendors. Were you honestly not aware of this? Try googling for "Git support".
      - elemeno 14y ago
        Which isn't quite the same as being able to get support from the company which built the software and who can push out a new release to fix the bug that you've just run into.
        phaemon 14y ago
        (is there a better way to do quotes on HN?) > Which isn't quite the same as being able to get support from the company which built the software I'm sure they'll build Git for you if you ask :) Do you think the original authors of Perforce etc. are still with the company? Are you under the impression that their current development team understand the Perforce source code far better than people providing professional Git support understand Git's? > and who can push out a new release to fix the bug that you've just run into. That's exactly what Git support can do. Why not? [edit: to clarify who "they" are]
        hanksf 14y ago
        Christopher Seiwald is still at Perforce. I would have to say: Yes, the current Perforce development team understands the Perforce source code intimately at least as well as the core developers of Git know Git, if not better. Disclaimer: I work for Perforce
- to3m 14y ago
  I don't think git can scale, at least not currently, to the extent perforce can. There's two main problems holding it back: - Storage of database on local drive - the last time I worked with perforce, HEAD alone was 280GB... where would this fit? (there's a presentation about google's use of perforce where they say the metadata alone for their database is >1TB! - so even storing just metadata might not fly) - As number of people using database increases, chance of needing to store hand-modified binary files (Office, Photoshop, Maya/Max/XSI/etc.) increases, and advantage to storing non-modified binary files (old builds, tools, etc.) increases. (Storing things in shares on people's PCs, or having two systems, or whatever, just ain't great.) Centralized locking is pretty much essential for such files, but, being centralized, it's hard to support with a distributed system... The former problem could almost certainly be solved. The latter I'm less sure about. Partly for technical reasons, but partly because the idea that binary files shouldn't be version-controlled is, for some people (and I don't know if the git people are of this mind), a point of inviolable principle.
  - lucisferre 14y ago
    You would be surprised. Git's differential compression is pretty impressive. I worked at an SVN show where HEAD was about 270mb but when I cloned it in Git the bare repo was only 130mb. Git also let's you clone parts of the tree and sections of the history (at least when working with SVN it did).
    - plorkyeran 14y ago
      That's mostly a SVN problem; checkouts are exceptionally large due to that they have a lot of metadata and a second copy of each file for local diffing/etc. which are uncompressed. Perforce doesn't do the same thing.
    - to3m 14y ago
      You may be right. My suspicion would be that a lot of the data is not terribly compressible, and that you'd be looking at over 1TB for the repository of a decent-size project. Add one checkout of head on top; add build products to that. Build products mount up surprisingly quickly, with multiple gigabytes of objects and PDBs being common. 1+TB (and git doesn't support partial checkouts) would make it difficult for people to work off a laptop, or use a SSD. Everybody would need 2 2TB drives on the off chance that they might have to work on more than one project at once. Or you'd have to check less stuff into the git repository. I know people say disk space is cheap; I just don't think it's quite cheap enough yet to piss away to this degree. It's one thing to have a server with masses of storage, I'm just not convinced you can require every client PC to have the same. I could be wrong.
- eob 14y ago
  Can the extensive code-review systems often layered on top of Perforce be achieved with git? As someone who has used both, the workflow features geared towards large organizations and professional-grade code processes have always struck me as a major feature of p4.
  - mullr 14y ago
    http://code.google.com/p/gerrit/ http://code.google.com/p/gerrit/
  - i386 14y ago
    Atlassian Stash was released recently with a code review process built around pull requests (For those that don't know, Stash is a Enterprise Git repository server) http://blogs.atlassian.com/2012/10/stash-13-enterprise-git-pull-request/ http://blogs.atlassian.com/2012/10/stash-13-enterprise-git-p... Disclaimer: I work for Atlassian
- icefox 14y ago
  Having helped several large companies migrate I would agree that this is a top concern, but it can be shown that Git can handle all of the users without any problem. Common tips like: If you are using pure ssh beyond 500 users you want to move away from the stock sshd. When possible setting up git to handle fetches over smart-http can scale git significantly (I would use all available bandwidth to the box before the cpu was anywhere near to pegged). The usual server side backups, routing and distributing load to local offices are all issues that are not too difficult to deal with. Even going through a worse case situation and on purpose corrupting the git database as an exercise is worth doing with new admin's. Inside the enterprise firewall there are a number of tools such as gitolite, github enterprise, gerrit, etc out there that are available to make the users and server admin's happy. Beyond that there are presentations, books, youtube videos, wiki's etc. I found making sure there is one "local export" really helps make things go smoother and and internal chat room / mailing list for Git can't hurt too. Slowly migrating users by teachings the early adopters with git-p4 also helps to prevent the sudden switch on "Monday" that goes horribly wrong causing everyone to loose a few days. The real problem has been shops that have 400GB perforce servers and they employed absolutely no rules about where things would live on the server. This would result in Perforce clients that would cherry pick directories from all sorts of random sub directories across the Perforce server to build a product (v.s. say something simpler like projectFoo/, 3rdparty/, and binaryTools/) The worst are the exceptions in the perforce client such as the perforce client would grab the src/ directory, but exclude src/vs/ because a few years ago someone checked in a visual studio install into the src directory and somewhere someone is still using it so they can't remove/move it... Even if they stick with Perforce companies like this really should clean up their repositories, call it simple professionalism. After a repository is cleaned up (even a basic pass can make a huge deal) then using git on top of perforce or even thinking of migrating is much easier to do. Using Git inside large companies is completely doable right now. In the past when Git was younger I gave a few presentations in the Boston area (where I live) to companies that were interested in learning more. If your in the area and if you just want to pick my brain on the topic or how it might apply to your situation I am always up for grabbing lunch.
  - to3m 14y ago
    What do you do about storing binary files in git? And is git not actually bothered by having a 400GB repository? I was under the impression that sort of thing was just not its intended use.
Jach 14y ago
git-p4 isn't really a good tool if your Perforce repo has branches... But you can get it to do the job with enough effort, and it's probably fine as a simple front-end (I never used it as such). My experience with it consisted of migrating LucidDB from its hosted Perforce server over to GitHub last year, which involved the fun process of learning how to graft new parent-child topologies into a git repo.

fghh45sdfhr3 14y ago

I like and occasionally use Git, but I started with Mercurial and still prefer it. Can anyone tell me why/how Git allegedly become way better than Mercurial? I seem to have missed that.

mercurial 14y ago
I haven't used Mercurial for a while, but on the top of my head: - lightweight branches (your branch is just a different head, there is nothing permanent about it) - git rebase -i (rewrite your history) - git add --patch (add parts of a file to a commit instead of the whole file) - the philosophy of preparing the commit by putting the files or portions of files you want to commit in the staging area, as opposed to committing everything per default I know Mercurial has alternatives to most of these functionalities, through various plugins. But I can't say I found them nearly as usable as Git. And that's saying something considering Git's command line interface.
msgilligan 14y ago
I don't think the article says Git is way better. It says it is way more popular, which is clearly true.

positr0n 14y ago

What is the git front end to perforce they talk about? All I know about is git-p4 (open source python script, still a little buggy last time I checked) and P4-Sandbox, which is supposed to be DCVS type features implemented in perforce. A real git front end would be awesome!

xgalvez 14y ago
Not sure it's a front-end (looks like it's a Perforce front-end to Git), but I believe it's an interface that makes the two work together: http://www.perforce.com/git-fusion http://www.perforce.com/git-fusion

sixothree 14y ago

The fact that the project managers and office staff at my workplace are unable to / incapable of using git is a deal-breaker. Git needs serious work in this regard.

jonpaul 14y ago
Shameless plug: http://gitpilot.com http://gitpilot.com this is part of the problem that we are trying to solve. We would love more feedback.
- thasmin 14y ago
  I'm not sure what gitpilot does. It's difficult to understand what's happening on the video. Two suggestions: 1. Windows client and 2. screenshots next to each of the six items on the page to demonstrate what you're explaining.
  - jonpaul 14y ago
    Thank you for your feedback. Of all of the market research that I've done so far, it seems that there still isn't a lot of Git developers on Windows. Outside of your own development, are many of your peers using Windows/Git? Excellent suggestion with the screenshots and the six items.
    - cbaleanu 14y ago
      Maybe I'm missing the point, but I'm using this http://windows.github.com/ http://windows.github.com/ and it's pretty good, specifically the shell.
synaesthete 14y ago
Git/most Git clients weren't designed for project managers or other document users. [shameless plug] Perforce has a new product (http://www.perforce.com/products/commons http://www.perforce.com/products/commons) that we're working on -- a client that IS designed for those folks/for document-sharing-and-versioning use cases. So if some developers are using Git, and the idea is to keep all company stuff in a clearly-shareable and accessible spot, Git + Git Fusion + p4 + Commons would do it. [Disclaimer: I work at Perforce, hence shamelessness of plug]

happypeter 14y ago

I've been a git super fun for years. But I have to say Hg is much more friendly to newbies. My reason for git's popularity is: The code is out of the hands of Linux kernel team, so you can believe that git will work well. And the fame of Linus and later github also count.

giulianob 14y ago
Github attracted a lot of the Ruby developers. They are extremely vocal on the web which I think is what made Github and Git so popular. I personally prefer Hg over Git as well due to friendlier syntax but Git hit it off a lot better w/ that vocal OSX community. I don't know many people who use Windows that like Git. The ports were buggy for a long time and the best visual tool, SmartGit, isn't free. Mercurial which has TortoiseHg which is excellent but I hear is painful to get running on OSX (maybe this has changed). Mercurial is fairly popular still though. I think a lot of people use it but not many popular articles get written about it the same way it does about Git.
- happypeter 14y ago
  Yes, ROR people talked a lot, on web, that also counts.

xgalvez 14y ago

In case people are wondering what the Perforce front-end/interface to Git was, I believe it's their "Perforce Git Fusion" product: http://www.perforce.com/git-fusion http://www.perforce.com/git-fusion Webinar's next week, and I may sign up to see what this is all about. (Disclaimer: Certified Perforce Admin here, and no, I don't work for Perforce.)

drudru11 14y ago

This would be a great story about 3 years ago