Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT

The Rise of Git 442

Posted by Soulskill from the git-on-up dept.
snydeq writes "InfoWorld takes a look at the rise of Git, the use of which has increased sixfold in the past three years. Buoyed in large part by interest among the Ruby community and younger developers, Git has been gaining share for open source development largely because of its distributed architecture, analysts note. And the version control system stands to gain further traction on Subversion in the years ahead, as Eclipse is making Git its preferred version control system, a move inspired by developers and members."
This discussion has been archived. No new comments can be posted.

The Rise of Git More

The Rise of Git

Comments Filter:

  • Github? (Score:3)

    by Sorthum ( 123064 ) on Tuesday July 26, 2011 @11:08PM (#36891082) Homepage

    This may be due in part to the way github integrates social networking and coding-- I'm unaware of anything similar for SVN, Perforce, Bazaar, Mercurial, etc...

    • Github, gitorious (we run an internal gitorious server.)

      I think the fact that its primary use case is the Linux kernel has been a huge selling point in terms of its ability to quickly and reliably handle huge development communities and codebases. That it basically came to be in the very pragmatic environment of the entire Linux community also helped, as it is being used for both open and closed source projects.

      All the other tools are too niche, proprietary, or were eclipsed by Git's exposure.

    • This may be due in part to the way github integrates social networking and coding-- I'm unaware of anything similar for SVN, Perforce, Bazaar, Mercurial, etc...

      What's that you say? Social networking and Git?! Now there's an idea! I'll go set up a new site - I'll call it GitFace! Who's in with me on the IPO in 2 years?

      • What's that you say? Social networking and Git?! Now there's an idea! I'll go set up a new site - I'll call it GitFace! Who's in with me on the IPO in 2 years?

        And I'll create the antisocial networking version called GitOuttaMyFace, et voila, between us, we have all of humanity covered.

        • Re: (Score:2)

          by grcumb ( 781340 )

          What's that you say? Social networking and Git?! Now there's an idea! I'll go set up a new site - I'll call it GitFace! Who's in with me on the IPO in 2 years?

          And I'll create the antisocial networking version called GitOuttaMyFace, et voila, between us, we have all of humanity covered.

          Well, I guess that leaves the porn site. I'm going to call it... <pimp voice>GitItOn</pimp voice>!

      • Re:Github? (Score:5, Funny)

        by mgiuca ( 1040724 ) on Tuesday July 26, 2011 @11:37PM (#36891214)

        Well that's really what GitHub is ... much like Facebook treats every "object" (status update, photo, event) as a commentable, likable object, so does GitHub for VCS objects such as commits.

        It's quite funny to see a commit with a comment thread attached to it. I saw one that went viral [github.com] and ended up with 88 comments including meme images.

        • Re: (Score:2)

          by ls671 ( 1122017 )

          Damn it guys, intelligent phones and what not that drive me crazy when everybody on the train look like silly ants typing endlessly on their tiny devices and now source control that integrates or offer similar functionality than Facebook ???

          I am putting a hold on our upgrade from CVS to Subversion project just in case, this sounds just too scary for me ;-)

  • Bazaar (Score:5, Insightful)

    by mgiuca ( 1040724 ) on Tuesday July 26, 2011 @11:16PM (#36891126)

    Yet another DVCS article that doesn't mention Bazaar at all. And cursorily swats away Mercurial as "not as large a community."

    It seems like just about every argument in favour of Git could be equally applied to any other DVCS. On top of that, the only thing it has going for it is a larger community (and being the creation of Torvalds).

    I've argued to wit's end that Bazaar is superior to Git in a multitude of ways (branches as separate file-system directories, optional ability to work in bound mode as with Subversion, revision numbers, explicit notion of a 'trunk' versus merged branches, explicit moves/renames rather than heuristics, commit metadata). Basically Bazaar has a much richer data structure than Git. The last point (commit metadata) is crucial: because Git lacks commit metadata, it is impossible to meaningfully use any other revision control system in conjunction with Git -- what a selfish decision.

    Yet all I ever hear is "Git is better than all the other revision control systems because [generic reasons why DVCSes are better than centralised ones]." Such is the case with Scott Chacon's site Why Git is Better Than X [whygitisbetterthanx.com], which I wrote a rebuttal of at Why Git Ain't Better Than X [wordpress.com].

    • Re:Bazaar (Score:4, Informative)

      by nschubach ( 922175 ) on Tuesday July 26, 2011 @11:27PM (#36891178) Journal

      The main problem I've had with Bazaar is the lack of tool options. Of course, that's not really Bazaar's fault...

      With Mercurial, I have tortoisehg for Windows and a very nice plugin for Eclipse. Bazaar's Eclipse integration has been rather lacking and the Windows tool chains have been slowly filing in, but it still needs time to level the field. (I'd work in Linux at work if it was an option... but it's not.) I still use Mercurial on my Linux laptop for local version management though.. mainly because it's what I use at work and there's no jumping between different keywords and methodologies.

      • Re: (Score:2)

        by mgiuca ( 1040724 )

        I don't really use tools other than the command-line, but I believe Bazaar has had TortoiseBzr included in the main Windows package for some time now. I don't think there's Eclipse integration though.

    • Re: (Score:2)

      by bgat ( 123664 )

      I tried Bazaar several times, and found its performance to be lacking, to say the least. Git runs circles around Bazaar for everyday commits, branching, and merging.

      And I think your complaint about git's lack of commit metadata is exceedingly theoretical. Why in the world would I want to simultaneously use two different configuration management systems on the same repository? I can't believe that need would come up except in situations where one is part-way through migration from one system to the other.

      • Re: (Score:2)

        by mgiuca ( 1040724 )

        I tried Bazaar several times, and found its performance to be lacking, to say the least. Git runs circles around Bazaar for everyday commits, branching, and merging.

        I've been using Bazaar for everything I do, large and small, for the past three years. I can't say I've ever noticed any delay in committing, branching or merging. Of course, if you are operating in bound mode (i.e., keep synchronised with the server) then it's a different story, but that's an optional feature that Git doesn't even have. From wh

    • Re: (Score:2)

      by euroq ( 1818100 )

      It seems like just about every argument in favour of Git could be equally applied to any other DVCS. On top of that, the only thing it has going for it is a larger community (and being the creation of Torvalds).

      So, given that statement, Git is better than any other DVCS. :)

      I've argued to wit's end that Bazaar is superior to Git in a multitude of ways (branches as separate file-system directories, ... explicit notion of a 'trunk' versus merged branches)

      Half of your ideas really ARE better; for example a revision number is superior to a SHA not just in an opinion, but in a quantifiable way. However, branches in separate file-system directories and trunk vs merged is a superfluous way of describing the same concept, which is branches, and Git (and others) still maintains that concept.

      I will argue, with both reason and experience, that separate directories for branches/trunks/tags are BAD. For

      • Re: (Score:2)

        by mgiuca ( 1040724 )

        Half of your ideas really ARE better; for example a revision number is superior to a SHA not just in an opinion, but in a quantifiable way. However, branches in separate file-system directories and trunk vs merged is a superfluous way of describing the same concept, which is branches, and Git (and others) still maintains that concept.

        Well of course Git has a concept of branches, but it only lets you access one at a time. What I find frustrating about this (besides the educational overhead of having to learn

        • Re: (Score:2)

          by euroq ( 1818100 )

          Well of course Git has a concept of branches, but it only lets you access one at a time. What I find frustrating about this (besides the educational overhead of having to learn how to switch branches, and figure out which ones are being pushed and to where) is the fact that there is no URL for identifying a particular branch in Git -- URLs identify repositories, and then branches are identified by additional syntax I still haven't grokked fully.

          I tend think the argument "I haven't learned it yet" isn't a good argument. Also, URLs identifying branches is syntactic sugar which doesn't affect the underlying system of the repository. The idea of only accessing one at a time has merit, but if you need that (like I do sometimes) you simply create two workspaces or checkout the files to a separate folder, both of which end up having the same effect as the Bazaar solution.

          When do you ever use relative paths that go up outside the current branch into another? If you ever did that (say, a file in 'trunk' refers to "../branch"), then it would break in Git anyway, where you can't refer to another branch. I think this is a non-argument. Besides, common practice in Bazaar is to have all the branches in one directory, and also have "trunk" in the same directory (it's just another branch, that happens to be called "trunk").

          This happened to me at a previous company using SVN. It had to do with the fact

          • Re: (Score:2)

            by mgiuca ( 1040724 )

            I tend think the argument "I haven't learned it yet" isn't a good argument.

            No, but "I've tried to learn it and it so far has confused the hell out of me" is grounds for an argument that something is hard to learn.

            if you need that (like I do sometimes) you simply create two workspaces or checkout the files to a separate folder, both of which end up having the same effect as the Bazaar solution

            Except with a major difference: Bazaar gives you the ability to have both checkouts share the same database, so it do

    • Bazaaars biggest problems was/is speed.

    • Re: (Score:2)

      by he-sk ( 103163 )

      Does Bazaar have a staging area?

      • Re: (Score:2)

        by mgiuca ( 1040724 )

        It has a "shelf" which is much like the Git staging area, only reversed. In Git, nothing is committed by default unless you stage it first. In Bazaar, everything is committed by default unless you shelve it first.

        This works the same in practice: if you want to commit only part of your changeset, first you shelve everything you don't want to commit, then commit, and then unshelve again. I find that I make far fewer "accidentally forgot to commit something" errors. (A friend of mine came all the way to work o

  • Names and such (Score:3)

    by girlintraining ( 1395911 ) on Tuesday July 26, 2011 @11:19PM (#36891142)

    Sometimes after spending a whole day amongst non-geeks, doing non-geeky things, I come here and read the names of some of the things these technologies are named.

    Git? Ruby? Subversion? Eclipse?

    I get this distinct hillbilly feeling after reading some of the names the open source community has come up with for their projects of late. Mental images of tie-clad programmers in a rusted pickup truck waving corded mice over their head while techno music plays kind of images. Then I hit page reload, and the feeling fades... until I think of Richard Stallman.

    • Re: (Score:2)

      by PCM2 ( 4486 )

      I get this distinct hillbilly feeling after reading some of the names the open source community has come up with for their projects of late.

      Well, then you're a weird and obsessive person.

      Photoshop? Windows? AutoCAD? WordPerfect? Dreamweaver? Flash? What kind of open source hillbilly would come up with names like that?

    • You are complaining about the name of software projects? Have you looked at the name of cars coming out recently?

    • Yeah, this is somewhat annoying about the *nix related culture, and sometimes they make adoption a bit harder for outsiders.

      But if you think THOSE names are weird, then you haven't really used any Linux distro, have you?

      The examples you've provided, aren't bad/weird names, in comparison.

      "Are you running that Debian derived distro, you know, the version Obtuse Ocelot? Ubuntu, that's it! Yeah, well I installed GIMP on there, because I wanted to make an image I could share through Apache, and burn on to a DVD

    • I get this distinct hillbilly feeling after reading some of the names the open source community has come up with for their projects of late.

      There's something about "gitorious" that doesn't square with the hills of the Appalacians. You can go too far. Feynman had a point in complaining about the brethren of the elusive squirtino, which is in the news lately.

      One the hillbilly side of the fence I've got a finger named "git". BitKeeper was a nice product, and a nice lesson. Thanks for all the fish may you r

  • I switched away from git to svn for a while since the "store the entire repository in your local project" design was killing my disk quotas, and I just didn't need all the fork/merge functionality so svn seemed simpler.

    After the half dozenth time of blowing away my local svn project because something was royally screwed up again I decided to go back to git.

    There's something to be said for a system that just works and doesn't end up with you spending hours screwing around with your version control system ins

    • Re: (Score:2)

      by euroq ( 1818100 )

      I checked out the full repository of an open source project I have been tinkering with in both SVN and Git (libgdx). The SVN was MUCH larger than the Git repository on my hard drive (i think 33% more, but I can't remember). There is something else one should realize when dealing with SVN... by having more files, you are by definition taking greater than or equal to the space of less files of the same length, due to file sectors (for example, a 1 byte file takes up a whole file sector, which is 4KB on my h

  • Lack of tooling (Score:3)

    by Luthair ( 847766 ) on Tuesday July 26, 2011 @11:27PM (#36891180)

    The lack of decent tools is going to slow adoption of git, particularly in corporations. I've yet to see a tool that can handle even a simple daily workflow so I've stuck to cli, gitk and git-gui which are all clunky. egit has definitely improved it still feels out of place and I believe is missing features (does it even support autocrlf yet?)

    Corporate projects will almost certainly have a centralized repository and while git can deal with this, its possible to paint yourself into a corner where its painful to recover.

    For reference, I've been a daily git user for ~16 months both at the company I work for and as a committer at Eclipse.

    • If you are on a Mac at least, you have a number of options - Tower is a very good client, though sort of expensive. GitHub has a well written Mac client app as well (it's free).

      There are other free solutions too, GitX is a pretty robust one.

      I find any of these handles day to day use of Git pretty well.

      • Re:Tower, GitHub, GitX client (Some Mac only) (Score:4, Interesting)

        by syzler ( 748241 ) <(ten.kedzys) (ta) (divad)> on Wednesday July 27, 2011 @12:42AM (#36891550)
        Let's not forget that Xcode 4 uses Git by default and is tightly integrated into the interface. Examples being
        • * Xcode creates a git repository by default when creating a new project
        • * When saving a file, Xcode will place a "M" marker next to a file to indicate it needs to be committed
        • * Re-naming a file in Xcode will perform the rm and add operations automatically in Git
        • * Xcode allows you to view the current version and past versions side by side in the editor

    • Re: (Score:2)

      by bgat ( 123664 )

      I've yet to see a tool that can handle even a simple daily workflow

      You seem to neglect the possibility that the workflow itself is broken. :)

      A centralized repository is a good thing for moving code between the developers and CM teams and, ultimately, on to release. But for daily development, forcing developers to all circle around a central repository a'la svn is a huge productivity killer. Git gives you the best of both worlds here.

      Some of my troubleshooting gets involved enough that I have to do local commits and branching, and stashing. I'd be considerably less produ

    • Sounds all too familiar.

      Last time I had to use it at a company a year ago the Eclipse integration was nowhere near the seamless integration Subclipse offers (user-friendly enough to let our graphics/layout guys use it without them having to ask us or jump through a ton of hoops because there isn't an intuitive UI).

    • Corporations are always the last, there are some which drop CVS now and move to SVN. By they time the seriously consider moving away from SVN hits toolchain support already will be mature.

    • Re: (Score:2)

      by euroq ( 1818100 )

      I hear you. I, almost daily, use three different tools on my Windows box for Git: GitExtensions, TortoiseGit, and the command line. I guess I occasionally use the Git+ GUI that comes with the binaries occasionally too, but only for 1 or 2 reasons that happen only once every month or two. Each of those tools can do something better than the other, and each of them also does something worse than the other.

      On top of that, I work with Mac users on my team, and they only use the command line for most operati

    • This is probably the only reason we're not seriously considering Git and use SVN instead, SVN works with anything nowadays.

  • I think Git has/had a lot of things driving people that way:

    1) Linus using Git of course drove a lot of Linux people to use it.

    2) As others have mentioned, huge use in the Ruby community

    3) GitHub, making it incredibly easy (or as easy as possible) for anyone to get started with a git project that would be hosted remotely.

    4) iPhone developers, there are quite a lot of them now and many have seemed to standardize on git (in fact it's the primary SCM supported by XCode now).

    Above all though I think it's probab

  • Git could use revision numbers (Score:4, Interesting)

    by euroq ( 1818100 ) on Wednesday July 27, 2011 @12:11AM (#36891414)

    Since the idea behind Git is that since it is distributed, and doesn't need a master repository, I guess it didn't make sense to have revision numbers when it was created (for the Linux kernel). This is because when two people make separate revisions at the same time on their local repositories, a linear revision number would conflict.

    However, I've never actually used any Git project/repository which didn't have a master repository. This is both local repositories for my own projects on my Dropbox folder, and professional repositories I've used (Android and the various repositories at the company I work at), And especially at work, it has been annoying that we didn't have revision numbers.

    I wish Git would get a new feature added: the ability to assign a repository as the "master" repository, and in turn the ability for the master repository to assign revision numbers. If people are wondering how that would work considering people make commits on their local repository and then push them to the master causing possible conflicts, the revision numbers wouldn't get assigned until they hit the master branch and they also split it up for merges:
          5
          / \
    4.1 4.2
        \ /
          3
    (or something similar to the above)

    Lots of people who use an alternative VCS like Mercurial, Bazaar, etc., bitch about Git because the lack of revision numbers. To those who are unfamiliar, each commit in Git has a SHA1 hash which is used as an identifier instead of a revision numbers. Unfortunately, they are very unwieldy to communicate to others. At work we always use the name and date-time instead, but that has problems as it doesn't convey the branch for instances when it matters.

    • Re: (Score:2)

      by siride ( 974284 )

      What problem do the revision numbers solve that tags or just using SHA1 ids (including the abbreviated ones) don't?

      • Re:Git could use revision numbers (Score:4, Interesting)

        by minkie ( 814488 ) on Wednesday July 27, 2011 @07:31AM (#36893396)

        Revision numbers are easier for humans to deal with. For example, here's a common flow I use every day:

        $ hg pull
        $ hg log | less { see some change I'm curious about and note the change number }
        $ hg export 3742 | less

        With change numbers, it's easy to remember 4 (or even 5) digits for the time it takes to type the export command. If I only had hashes, I'd have to copy-paste the string. Things like this matter less to people who only use GUIs. For command line folks, however, being able to easily read, pronounce, remember, and type change numbers is essential. Even if you're just talking with other people, it's a lot easier to say, "Oh, I see what happened, in change 2456, you did..." than to refer to hash strings.

        I've used rcs, cvs, clearcase, perforce, dabbled in svn, dabbled in git, and am currently using hg. Of the centralized bunch, perforce is my favorite (not free, but reasonably priced and amazingly excellent tech support). I can't see anybody wanting to use svn for any new projects today. When it first came out, it was a a significant improvement over cvs and people naturally flocked to it, but there's just so many better alternatives today.

        Clearcase is an interesting beast. For sure, it's overpriced bloatware that's on life support, being kept alive mostly by big legacy customers with neanderthalic IT and Release Engineering departments who still believe IBM can do no wrong. But, it did have some interesting ideas. That every revision of every file exists simultaneously in the file system namespace is really powerful.

        Between git and hg, I'd say they are fundamentally identical in capability, but I find the hg command set easier to get my head around. All the people who say, "X is the best possible vcs. I used to use cvs and when I switched to X my sex life improved overnight", fail to understand that "X is way better than cvs" is true for pretty much any value of X, and says nothing about the relative merits of the various X instances.

    • Re: (Score:3)

      by mgiuca ( 1040724 )

      That would certainly help. I was extolling the merits of Bazaar's revision numbering scheme on my post above (titled "Bazaar"). The problem as I see it is that unlike Bazaar, Git doesn't assign any significance to the master parent of a commit. I'll shamelessly rip some text from my own explanation above:

      For example, in Git, when you commit a merge (say, from a feature branch to master), you create a commit object with two parents, in no particular order: a) the most recent commit on the master, and b) the

    • Yes, for a git user the sha key is effectively the commit id / revision number, and it works incredibly well. I don't miss the crazy multi-dotted revision numbers from e.g. CVS, or even the simplified version numbers from svn, or anything else. The sha commit id works so well in git that our kernels include the first few digits of it in their version string printed out in the dmesg, which makes figuring out the basis for a bug report very easy.

      Our use of git effectively has a master repo as well, and it i

  • PostgreSQL CVS-git conversion (Score:5, Interesting)

    by greg1104 ( 461138 ) <gsmith@gregsmith.com> on Wednesday July 27, 2011 @12:46AM (#36891578) Homepage

    I had a small role in getting the PostgreSQL project to convert from CVS to git. There's a good summary of what happened at Lessons from PostgreSQL's Git transition [lwn.net]. With a pretty conservative development community, the bar for converting from CVS to git was set pretty high: the entire CVS repository had to come through, such that every single release ever tagged could be checked out and get exactly the same files as checking it out of CVS (a little binary diff tool was used to confirm). With around 15 years of history in there, that took some upstream fixes to the cvs2git tool to finally accomplish; it took just over a year to work out all the details to everyone's satisfaction. My checked out copy of the current repo is 272MB right now, so neither small nor giant.

    I would say that everyone who works regularly on the code is at least a little bit more productive than they used to be, with the older CVS experts having seen the least such improvement. But some people are a whole lot more productive. I'd put myself in that category--my patch contribution rate is way up now that it's so much easier to pop out a branch to hack on some small thing and then submit the result for review.

    And the conversion seems to have improved the uptake of new developers getting involved in working on the code. Having to deal with CVS was a major drag for younger developers in particular, and Subversion is equally foreign to most of them now. As suggested in the article, anyone under 25 will only touch a corporate style CVS or Subversion repo if dragged kicking and screaming into it. As more of that generation rises through IT, old style repos will continue to get shredded at a good rate every year. It could have been any of the DVCS systems that ended up in this position, but git was the one that got the right balance of feature, innovation rate, and publicity. Now that it's got such a wide user base, too, I don't see any of the other VCS software options competing with it successfully in the near future.

    • Re: (Score:2)

      by euroq ( 1818100 )

      Interesting.

      I would argue to the old-school developers that there is absolutely, positively, 100% no reason to ever use CVS in 2011. There is absolutely no advantage that CVS has over modern VCS's.

  • Whatever happened to to Tom Lord's Arch? (Score:3)

    by Relyx ( 52619 ) on Wednesday July 27, 2011 @03:18AM (#36892156)

    Tom Lord, developer of rival Arch must be spitting blood at the success of Git.

    I followed Arch's development back in 2004 and quickly lost interest. The last crazy thing I remember was Tom trying to build a home-brew LISP derivative *into* his version control system. It was going to revolutionise everything. He even wrote a long manifesto-cum-design document in three parts. At that point I gave up and moved to Subversion. I just wanted a modern version control system that worked.

    • Re: (Score:3)

      by paskie ( 539112 )
      Actually: http://wiki.bazaar.canonical.com/HistoryOfBazaar [canonical.com] Bazaar pretty much evolved from GNU Arch, though it is of course a very different beast now and there is AFAIK no shared code - but the developers migrated there from a GNU Arch branch and they took some ideas with them, so it still can be seen as a spiritual successor. :-)

  • Mercurial for the Win (Score:3, Informative)

    by cowwoc2001 ( 976892 ) on Wednesday July 27, 2011 @09:36AM (#36895064)

    Mercurial has 95% of Git's functionality and is far easier to use. The extra features are simply not worth the headache.

    Git's Windows support is atrocious. The installation process is an easy indication of that. Mercurial is packed of "just works" moments.

Slashdot Top Deals

"I got everybody to pay up front...then I blew up their planet." "Now why didn't I think of that?" -- Post Bros. Comics

Close