9 ms·

I find git's growth and adoption remarkable. It was only 5 years ago that as a young programmer I was first exposed to git and the concept of version control. I

by ultimoo 12y ago

I find git's growth and adoption remarkable. It was only 5 years ago that as a young programmer I was first exposed to git and the concept of version control. I remember that every other team I knew at my organization was using svn and no one really understood how git could improve their workflow or how it worked and what it brought to the table. Now that I look around, almost everyone in the programming world (at least the part I'm exposed to) is familiar with git as a version control software and github as a social-coding/code-hosting site.

joeblau 12y ago
Yeah, I just picked up git about 3 years ago and I probably wouldn't even take a job if they were using one of the other DVCSs.
- delive 12y ago
  I've been using git-svn for workflow the past 2 years or so. It's not perfect, but it seems to cover all the use cases I've had and integrates well with the regular svn workflow.
- eddieroger 12y ago
  I really hope you're being sarcastic. If you're turning a job down because of the VCS, hopefully you've got a surplus of work to choose from.
  - zbowling 12y ago
    engineers do in the bay area.
    - balls187 12y ago
      and in seattle
  - zellyn 12y ago
    I understand the sentiment: the fact that a company uses Visual Sourcesafe, or ClearCase, or something else terrible tells you a lot about their culture.
  - throwaway5752 12y ago
    I'd be inclined to agree with you in some cases ("any port in a storm"), but otherwise I would view a VSS or ClearCase shop as one that's possibly on the wrong side of the technology curve. I have worked with VSS, p4, cvs, svn, hg, and git (and arms length with evil things like ClearCase and more primitive stuff like RCS). Everyone should have an idea of the minimal toolchain they want to work with. But that aside.. massive props to the Git team on 2.0!
    - zimpenfish 12y ago
      First month at the previous gig was spent writing an SVN-based implementation of SCCS because their workflow required SCCS locking etc. and they wanted to move the backend to SVN for the eventual "moving the developers to not all working in the same directory" project. It was a very tearful month.
- damncabbage 12y ago
  I can almost understand with something like Subversion (which seems to subtly skew the entire development process to work around the friction some of its basic operations introduce), but not even Mercurial? :(
  - joeblau 12y ago
    Not even Mercurial :) Haha j/k I actually don't mind Mercurial, but I'd still rather work with git.
    - crdoconnor 12y ago
      They're essentially identical. Mercurial just has slightly easier to understand syntax and and a cultural bias against rebasing.
      - anton_gogolev 12y ago
        Nope. Mercurial devs rebase heavily during Mercurial development, for instance. It's Changeset Evolution [1] that makes history rewriting _safe_. [1]: http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution
- malkia 12y ago
  A lot of game studios use Perforce (p4) - while it's not distributed, it seems to be easier to non-programming folks - artists, producers, etc. And git can still be used along with it - For some of the lib/tools that I do, I create a ".git" repository living along with p4, and work like this - then submit in P4.
  - SoftwareMaven 12y ago
    Perforce also handles large binary blobs better as well, which is super important in game programming.
    - yoklov 12y ago
      Where I work (game company with about 20 people) we solve this by versioning unimported assets separately (in svn, because that's what we used before git). We bring them into the git repo after running them through our asset pipeline, which means that there are really never any merge conflicts for them and every checkout is a playable version of the game with art. This reduces the load on git by a lot, though we still tend to have .git folders measured in the tens of gigabytes, which is getting up there.
  - zanny 12y ago
    How is git with a gui hard for artists? I get that they don't want to stage their changes and commit them from a terminal, but you literally just pick your files and write a note about what you did before hitting the commit button.
    - rtpg 12y ago
      I think perforce deals with binary files better too (not sure of the details)
    - virtue3 12y ago
      git does have very very bad binary asset management. It doesn't really work like svn/perforce in a logical tree structure and each commit has it's own hash and isn't necessarily ordered so there ends up being a _lot_ of copies of binary assets (git -unconfigured- will attempt to store deltas between changes but it can't do that with binary assets... and over time gets _very_ slow with large binary assets). This isn't necessarily horrid for web apps as the images aren't big. But when you're talking about 500mb PSD files and massive massive 3d maya/max scenes it's horrid. http://stackoverflow.com/questions/3055506/git-is-very-very-slow http://stackoverflow.com/questions/3055506/git-is-very-very-...
- Walkman 12y ago
  > I probably wouldn't even take a job if they were using one of the other DVCSs. Why? At my current workplace, I converted a svn repository (with 6 years of commits) to git without any hiccups! I did not even lost a single commit! I also detached a huge binary directory (they committed everything to svn...) and made a different repo for it. Also you got git-svn, with you can seamlessly commit to an svn repo and still work in git on your local machine, nobody will notice, except you!
- deleted 12y ago
  [deleted]
ams6110 12y ago
Just be glad you never had to use Visual Source Safe. Makes svn look like a dreamland.
- virtue3 12y ago
  after having to use it for one job it is now a required question I have about the organization using git/mercurial/perforce before I'll accept a job offer.
- aaronbrethorst 12y ago
  My first job out of college happened to involve me working tangentially with the folks who maintained Visual SourceSafe. They didn't particularly like it either ;)
- yen223 12y ago
  Once upon a time, I actually thought VSS was the shit. But that's because crappy source control is better than no source control.
  - billybiro 12y ago
    I beg to differ. Take a little look at this: http://www.highprogrammer.com/alan/windev/sourcesafe.html http://www.highprogrammer.com/alan/windev/sourcesafe.html At least with NO version control, you know you're not protected. Bad version control, such as VSS, gives a false sense of security that you're protected when you're really not, which is worse.
- nu2ycombinator 12y ago
  And clearly you never had to use "clearcase" then :)
  - davidgerard 12y ago
    OH GOD CLEARCASE I put ClearCase on an old version of my CV, because I was nominally the sysadmin in charge of it for six months. I still get calls about it. Those last ClearCase shops, they're getting desperate.
benihana 12y ago
Well said. The funny thing is, switching from svn to git was what it felt like to switch from from other SCMs to svn. I think git is going to prove to be one of those pieces of software that is just transcendent.
- WalterBright 12y ago
  git (and github) has been transformative for the D programming language project, as it allows easy collaboration with people all over the world.
jaseemabid 12y ago
Its a surprisingly awesome s/w for a '2.0'
jasonkester 12y ago
I've been using git (and GitHub) at my day job for a couple years now, and I'm still not sure I'm sold on it over Subversion. In the past, version control was something that existed but you never had to think about. When you got to a good place, you'd hit the big red Save Button and up your code would go. Once in a blue moon you'd step on somebody's changes and have to do a quick merge. No big deal. Now with Git, version control is part of the workflow. It's never far from your mind. You're creating branches before writing code (versus creating branches three times a year when you needed them). You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes back into the IDE just so that the source control system (and possibly some ops overlord somewhere) doesn't get mad at you. I'm sure there are times where Git has actually made things easier, but most of the time it's just one extra thing taking up my attention. It's like timesheets for your code. Not a big deal, but ever so slightly insulting that you have to deal with them.
- darkFunction 12y ago
  > You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes back into the IDE just so that the source control system (and possibly some ops overlord somewhere) doesn't get mad at you. I'm sure if you were a release manager, or the lead of a sizeable team, or the owner of a busy open source project, you would feel very differently about 'silly' modularised changesets and branching.
  - m_eiman 12y ago
    I don't get this "it makes things easier for a select few, so everyone else just has to suffer an over complicated system" thing. We should make the few suffer instead of the masses; optimize to lower global suffering. It should be possible to build a system that exposes different interfaces to different users, shouldn't it?
    - kryptiskt 12y ago
      This guy in the crowd finds it very convenient to be able to commit locally so that you can easily get back to an earlier state of the thing when you fuck up or wants to explore another way to do it. The masses have spoken and they want git.
jammycakes 12y ago
You can get some interesting usage statistics from job tracking websites such as itjobswatch.co.uk. In the source control market, Git is now the most widely used (3461 jobs) with Subversion second (3181) and TFS third (2035). Mercurial is a distant fourth with 268 and just about everything else seems to have fallen off a cliff in the past couple of years or so. The other thing that Git has achieved is that it is now the de facto standard for source control in a way that no other source control tool has ever been. An increasing number of ecosystems don't support anything else and most best practice guidelines that you find on the web assume that you're using it, or else tell you to switch if you aren't. I suspect that it won't be long before not using Git will start to count against you in the jobs marketplace, whether you're a candidate or a recruiter.

by ultimoo 12y ago

joeblau 12y ago

Yeah, I just picked up git about 3 years ago and I probably wouldn't even take a job if they were using one of the other DVCSs.

delive 12y ago
I've been using git-svn for workflow the past 2 years or so. It's not perfect, but it seems to cover all the use cases I've had and integrates well with the regular svn workflow.
eddieroger 12y ago
I really hope you're being sarcastic. If you're turning a job down because of the VCS, hopefully you've got a surplus of work to choose from.
- zbowling 12y ago
  engineers do in the bay area.
  - balls187 12y ago
    and in seattle
- zellyn 12y ago
  I understand the sentiment: the fact that a company uses Visual Sourcesafe, or ClearCase, or something else terrible tells you a lot about their culture.
- throwaway5752 12y ago
  I'd be inclined to agree with you in some cases ("any port in a storm"), but otherwise I would view a VSS or ClearCase shop as one that's possibly on the wrong side of the technology curve. I have worked with VSS, p4, cvs, svn, hg, and git (and arms length with evil things like ClearCase and more primitive stuff like RCS). Everyone should have an idea of the minimal toolchain they want to work with. But that aside.. massive props to the Git team on 2.0!
  - zimpenfish 12y ago
    First month at the previous gig was spent writing an SVN-based implementation of SCCS because their workflow required SCCS locking etc. and they wanted to move the backend to SVN for the eventual "moving the developers to not all working in the same directory" project. It was a very tearful month.
damncabbage 12y ago
I can almost understand with something like Subversion (which seems to subtly skew the entire development process to work around the friction some of its basic operations introduce), but not even Mercurial? :(
- joeblau 12y ago
  Not even Mercurial :) Haha j/k I actually don't mind Mercurial, but I'd still rather work with git.
  - crdoconnor 12y ago
    They're essentially identical. Mercurial just has slightly easier to understand syntax and and a cultural bias against rebasing.
    - anton_gogolev 12y ago
      Nope. Mercurial devs rebase heavily during Mercurial development, for instance. It's Changeset Evolution [1] that makes history rewriting _safe_. [1]: http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution
malkia 12y ago
A lot of game studios use Perforce (p4) - while it's not distributed, it seems to be easier to non-programming folks - artists, producers, etc. And git can still be used along with it - For some of the lib/tools that I do, I create a ".git" repository living along with p4, and work like this - then submit in P4.
- SoftwareMaven 12y ago
  Perforce also handles large binary blobs better as well, which is super important in game programming.
  - yoklov 12y ago
    Where I work (game company with about 20 people) we solve this by versioning unimported assets separately (in svn, because that's what we used before git). We bring them into the git repo after running them through our asset pipeline, which means that there are really never any merge conflicts for them and every checkout is a playable version of the game with art. This reduces the load on git by a lot, though we still tend to have .git folders measured in the tens of gigabytes, which is getting up there.
- zanny 12y ago
  How is git with a gui hard for artists? I get that they don't want to stage their changes and commit them from a terminal, but you literally just pick your files and write a note about what you did before hitting the commit button.
  - rtpg 12y ago
    I think perforce deals with binary files better too (not sure of the details)
  - virtue3 12y ago
    git does have very very bad binary asset management. It doesn't really work like svn/perforce in a logical tree structure and each commit has it's own hash and isn't necessarily ordered so there ends up being a _lot_ of copies of binary assets (git -unconfigured- will attempt to store deltas between changes but it can't do that with binary assets... and over time gets _very_ slow with large binary assets). This isn't necessarily horrid for web apps as the images aren't big. But when you're talking about 500mb PSD files and massive massive 3d maya/max scenes it's horrid. http://stackoverflow.com/questions/3055506/git-is-very-very-slow http://stackoverflow.com/questions/3055506/git-is-very-very-...
Walkman 12y ago
> I probably wouldn't even take a job if they were using one of the other DVCSs. Why? At my current workplace, I converted a svn repository (with 6 years of commits) to git without any hiccups! I did not even lost a single commit! I also detached a huge binary directory (they committed everything to svn...) and made a different repo for it. Also you got git-svn, with you can seamlessly commit to an svn repo and still work in git on your local machine, nobody will notice, except you!
deleted 12y ago
[deleted]

ams6110 12y ago

Just be glad you never had to use Visual Source Safe. Makes svn look like a dreamland.

virtue3 12y ago
after having to use it for one job it is now a required question I have about the organization using git/mercurial/perforce before I'll accept a job offer.
aaronbrethorst 12y ago
My first job out of college happened to involve me working tangentially with the folks who maintained Visual SourceSafe. They didn't particularly like it either ;)
yen223 12y ago
Once upon a time, I actually thought VSS was the shit. But that's because crappy source control is better than no source control.
- billybiro 12y ago
  I beg to differ. Take a little look at this: http://www.highprogrammer.com/alan/windev/sourcesafe.html http://www.highprogrammer.com/alan/windev/sourcesafe.html At least with NO version control, you know you're not protected. Bad version control, such as VSS, gives a false sense of security that you're protected when you're really not, which is worse.
nu2ycombinator 12y ago
And clearly you never had to use "clearcase" then :)
- davidgerard 12y ago
  OH GOD CLEARCASE I put ClearCase on an old version of my CV, because I was nominally the sysadmin in charge of it for six months. I still get calls about it. Those last ClearCase shops, they're getting desperate.

benihana 12y ago

Well said. The funny thing is, switching from svn to git was what it felt like to switch from from other SCMs to svn. I think git is going to prove to be one of those pieces of software that is just transcendent.

WalterBright 12y ago
git (and github) has been transformative for the D programming language project, as it allows easy collaboration with people all over the world.

jaseemabid 12y ago

Its a surprisingly awesome s/w for a '2.0'

jasonkester 12y ago

I've been using git (and GitHub) at my day job for a couple years now, and I'm still not sure I'm sold on it over Subversion. In the past, version control was something that existed but you never had to think about. When you got to a good place, you'd hit the big red Save Button and up your code would go. Once in a blue moon you'd step on somebody's changes and have to do a quick merge. No big deal. Now with Git, version control is part of the workflow. It's never far from your mind. You're creating branches before writing code (versus creating branches three times a year when you needed them). You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes back into the IDE just so that the source control system (and possibly some ops overlord somewhere) doesn't get mad at you. I'm sure there are times where Git has actually made things easier, but most of the time it's just one extra thing taking up my attention. It's like timesheets for your code. Not a big deal, but ever so slightly insulting that you have to deal with them.

darkFunction 12y ago
> You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes back into the IDE just so that the source control system (and possibly some ops overlord somewhere) doesn't get mad at you. I'm sure if you were a release manager, or the lead of a sizeable team, or the owner of a busy open source project, you would feel very differently about 'silly' modularised changesets and branching.
- m_eiman 12y ago
  I don't get this "it makes things easier for a select few, so everyone else just has to suffer an over complicated system" thing. We should make the few suffer instead of the masses; optimize to lower global suffering. It should be possible to build a system that exposes different interfaces to different users, shouldn't it?
  - kryptiskt 12y ago
    This guy in the crowd finds it very convenient to be able to commit locally so that you can easily get back to an earlier state of the thing when you fuck up or wants to explore another way to do it. The masses have spoken and they want git.

jammycakes 12y ago

You can get some interesting usage statistics from job tracking websites such as itjobswatch.co.uk. In the source control market, Git is now the most widely used (3461 jobs) with Subversion second (3181) and TFS third (2035). Mercurial is a distant fourth with 268 and just about everything else seems to have fallen off a cliff in the past couple of years or so. The other thing that Git has achieved is that it is now the de facto standard for source control in a way that no other source control tool has ever been. An increasing number of ecosystems don't support anything else and most best practice guidelines that you find on the web assume that you're using it, or else tell you to switch if you aren't. I suspect that it won't be long before not using Git will start to count against you in the jobs marketplace, whether you're a candidate or a recruiter.