Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
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

Comments Filter:
  • 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:It's because (Score:4, Informative)

    by bgat (123664) on Tuesday July 26, 2011 @11:30PM (#36891190) Homepage

    I'm not aware of any _code_ sets which span 50GB, and it seems unlikely that you could get to that size without a lot of machine-generated content. Such content wouldn't be ideal for git to manage, since git depends a lot on the capabilities of diff--- and machine-generated content might not diff as effectively as human-generated code. You can hardly fault a tool for doing a poorly at a job it wasn't designed to do.

    Is the content you are managing that you describe as "50GB+" actually human-generated _code_? Or is it _data_? There is a big difference to git.

    On the other hand, git manages the complete Android source code. It isn't "50GB+", but it is still substantially larger than the Linux kernel--- and git does fine. However, Google breaks that code base up into 150+ sub-repositories, which is actually a quite sane thing to do. I haven't tried to place Android into a single git repository, so I can't say how well git would deal with something that large. But it wouldn't be the best way to use git, anyway.

    So I think your negative review of git is uninteresting, to say the least.

  • by syousef (465911) on Tuesday July 26, 2011 @11:48PM (#36891286) Journal

    Exactly who the fuck has 50GB in one source code tree?

    --
    BMO

    Those who store data, images, other binaries like built executables and other artifacts alongside the code.

    You can argue that you shouldn't do that, but there are times when it's difficult to avoid, and if you need to be able to keep versions, it can be done easily with something like SVN.

    I think GIT has it's advantages, but to reject all predcessors and raise it up as the only way to go is foolish.

  • by siride (974284) on Wednesday July 27, 2011 @12:03AM (#36891364)

    I store binary data in my Git repos and it doesn't seem to balloon as badly these days as people make it out to be.

    In fact, Git seems to be good enough at it that I use it to do application releases. It's faster for me to build an app, commit it to a special Git repo and push the new commit, than to send it via SFTP over the VPN (a few hundred KB vs dozens of MB). In that repo, I have hundreds of new versions, but it's only a few hundred megabytes. The equivalent in file storage would be easily ten times as much.

    I don't doubt that other VCSes do better, but Git is not awful.

  • Re:It's because (Score:4, Informative)

    by wagnerrp (1305589) on Wednesday July 27, 2011 @12:13AM (#36891418)

    With git, you have no option to pull the entire repository, and all of its data, and all of its history. Aptly described by the command, you have your own local clone of the whole thing. As such, with larger projects, it becomes necessary to break the repository up into smaller, more manageable submodules. If using subversion, or some other version control system where you 'check out' rather than 'clone', it becomes possible to simply pull the current version of just the directory you want to work on. In essence each folder is automatically made a submodule.

    Both strategies have their advantages and disadvantages. Every programmer is going to have their own style of work, which will be better suited towards one VCS or another. Claiming git is the perfect VCS for all occasions, as the OP did, is simply naive.

  • Re:It's because (Score:4, Informative)

    by m.dillon (147925) on Wednesday July 27, 2011 @01:39AM (#36891762) Homepage

    Yes, but at the same time I only recall a few minor instances where I ever wanted to extract just a portion of a CVS archive, and the only reason was because, at the time, the system I was running on wasn't all that fast.

    These days extracting a repo, even a large one, doesn't take all that much time, nor is disk space that big an issue. I just extract the whole thing (git, cvs, whatever) and then pick out what I want.

    It only takes ~3 seconds or so to switch branches on a checked out repo of around ~100,000 files, and certainly less than ~10 seconds to do an initial checkout of such a repo. Not to mention the fact that 2TB hard drives are $100 these days so there's no real excuse to be tight on disk space.

    When I first started using git I did worry somewhat about disk space. I quickly came to the conclusion that a few extra gigabytes didn't matter in today's world of cheap multi-terrabyte hard drives. I typically have 4-5 copies of the DragonFly source base broken out, each with its own copy of the .git repo. A simple git pull is all I need to synchronize whatever directory I've decided to work in (since I'm often reviewing other developer's branches I have multiple independent copies). That's how little I care these days.

    That said, it *is* possible to tell git to hard links or otherwise share repo files in order to reduce the size of the .git/ subdirectory in the checkout directories. We do this on our developer box (where each account is given its own private repo which syncs against the DragonFly master repo). I don't bother optimizing my own personal copies though.

    And one final thing to note... if the filesystem can de-duplicate data, having a lot of copies lying around is even less of an issue. I've never had to depend on de-dup... it's kinda hard to actually run a 2TB drive that isn't being used to archive media files out of space... but it does work particularly well on backup machines.

    -Matt

  • Re:It's because (Score:5, Informative)

    by buchner.johannes (1139593) on Wednesday July 27, 2011 @02:54AM (#36892070) Homepage Journal

    see "git clone --depth" [die.net]

  • by mfwitten (1906728) on Wednesday July 27, 2011 @05:15AM (#36892672)

    Now, Git works around this mostly, because you can say 483b3ced^ to go to the previous revision (and actually SVN supports this too because you can say HEAD^). But it's not a full solution. What's the next revision? Git doesn't have a way of getting you that information.

    That question doesn't make any sense, because in absolute terms, there are an indeterminate number of immediate children across every repository and across time.

    There are a number of things you could do to narrow the search (such as something like git log --reverse -1 483b3ced..master, but ultimately you'd have to account for merge commits there, too; perhaps the --children flag for git rev-list and git log might be useful).

  • 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.

Science and religion are in full accord but science and faith are in complete discord.

Working...