The Rise of Git 442
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."
Github? (Score:3)
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...
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)
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)
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)
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)
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 ;-)
Re: (Score:2)
Bitbucket doesn't have the features that Github has. On bitbucket, pull requests are basically email notifications to the repo managers. On github, you can view changesets and now you can even do one click merging once the changes have been reviewed. There are a bunch of other features also that bitbucket just doesn't have yet. Hopefully bitbucket will improve because it will be good to have the competition to drive features.
Re: (Score:2)
There is one thing but bucket has which is vital, they have free private repos, in github you have to pay for them.
Bazaar (Score:5, Insightful)
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)
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)
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)
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)
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)
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)
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)
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)
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.
Except with a major difference: Bazaar gives you the ability to have both checkouts share the same database, so it do
Re: (Score:2)
Bazaaars biggest problems was/is speed.
Re: (Score:2)
Does Bazaar have a staging area?
Re: (Score:2)
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
Re: (Score:3)
From what I know about git-notes, they are a relatively new concept and aren't very well supported. Apparently they don't survive being pushed and pulled by default [nabble.com] (that's worse than it may seem -- it isn't sufficient for me to ensure they are pushed; everybody who takes a copy of the repo has to as well).
Integrating one VCS persistently with another relies on storing foreign VCS data in the metadata of the primary system -- if the primary system loses the metadata you are hosed. So for now, using Bazaar (
Re: (Score:2)
I'm not sure that repo-managed commit meta-data is necessarily a good thing, other than having the (obvious) log entry. Meta-data is so project-dependent that it is probably better to implement it as a wrapper and store it as a file within the repo instead of trying to integrate it with the repo.
Among other things, anyone who's tried to manage meta-data in repos for any length of time knows how nasty things can get when you need to edit previously committed meta-data. In otherwords, meta-data management c
Re: (Score:3)
An important distinction with Subversion (which I think handles branches atrociously): In Subversion, branches are separate folders within the repository; a repository has a single linear history with branch directories inside of it. In Bazaar, branches are separate folders outside of the repository; each branch has its own history and branches are treated as separate objects. Sorry if I didn't make that clear.
As for revision numbers, on the contrary: they aren't really meaningful until you start doing non-
Re:Bazaar (Score:4, Interesting)
Your cite branches in separate folders as a superior feature? Subversion has that crap and it's messy.
High five brah! I hated that shit when I had to use SVN.
You also mention "revision numbers" as a feature. Who gives a crap about revision numbers?
As a person who has professionally used Git (and likes it) in many repositories, both large and small, I miss revision numbers. When I e-mail my colleagues about commits (i.e. revisions in another syntax), it is annoying to communicate it: I have to copy and paste the entire commit metadata (name, author, date-time, and SHA) in order to reflect it properly. I would much rather say "15.1" or "newfeaturebranch.3".
It also has been a problem when using the "Blame..." tool to track down why something was changed, as you have to do a double-lookup to find the SHA of the changed line and then the commit of the SHA. Well, my bad because really you'd have to do the same thing with a revision number, but trust me... I'd rather be working with revision numbers than SHAs because it would be easy to know that this line was changed because of "newfeaturebranch" rather than e93f02a09f9fe092a039a923.
Obviously, we don't need revision numbers... but boy would I love to have them.
Re: (Score:3)
Why? DVCS systems are great for bazaar style open source projects like linux but I don't think they are appropriate for every case. At least with hg anyone who wants to work on the code has to download the entire history of the entire repositry. That is fine if the codebase is relatively small and the users can find a fast connection for initial checkout. Not so great if you are trying to track the complete history of a large project including all the tooling needed to successfully build it.
Re: (Score:2)
Someone already mentioned this [slashdot.org]. I'll paste what I said above there (and it's backed up by your second link [progit.org] too, see the section "Sharing Notes"):
From what I know about git-notes, they are a relatively new concept and aren't very well supported. Apparently they don't survive being pushed and pulled by default [nabble.com] (that's worse than it may seem -- it isn't sufficient for me to ensure they are pushed; everybody who takes a copy of the repo has to as well).
Integrating one VCS persistently with another relies on sto
Names and such (Score:3)
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)
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?
Re: (Score:2)
You are complaining about the name of software projects? Have you looked at the name of cars coming out recently?
Re: (Score:2)
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
hillbillies with cultural agendas (Score:2)
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
because the others still suck (Score:2)
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)
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
Re: (Score:2)
You can use git show and git archive to spit out individual files or directories of the repo for any previous commit. While it's one slightly extra step, it's pretty flexible and applies not just to branches, but to all commits.
Lack of tooling (Score:3)
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.
Tower, GitHub, GitX client (Some Mac only) (Score:2)
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)
Re: (Score:2)
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
Re: (Score:2)
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).
Re: (Score:2)
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)
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
Re: (Score:2)
This is probably the only reason we're not seriously considering Git and use SVN instead, SVN works with anything nowadays.
A number of large external factors in adoption (Score:2)
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)
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)
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)
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, Informative)
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).
Re: (Score:2)
That's precisely why most DVCS don't use version numbers, but you'll also notice that the poster who started this thread proposed having a master repository which sets the numbers.
You'll also notice I didn't say "DVCS should have version numbers" in my post, I said "here are the drawbacks with the fact that DVCSs don't (usually) have version numbers."
Also you could look at Bzr... another poster in this thread has elaborated on the way it does numbering in a distributed setting.
Re: (Score:3)
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
Re: (Score:3)
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)
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)
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)
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)
Mercurial for the Win (Score:3, Informative)
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.
Re: (Score:3)
Re:It's because (Score:4, Funny)
and saturnial is even better of course although I hear that aluminiumal is doing well too ;-)
Re: (Score:2)
I couldn't agree more heartily. We (I) just made a clean cut over to Git at work last week (from CVS... ew), and it's the greatest thing since sliced bread.
I don't Git it.... (Score:2)
Git has some nice advantages, especially in distributed environments.. but I still prefer svn because it's just a lot easier to use. I'm sure it's good for merging, but as a developer it ends up being a headache. For instance, if you want to check in a group of specific files and not every change you've made.. PITA
Re: (Score:2)
Both SVN and Git can handle only checking in a few changes, although Git has nicer tools built-in for committing only particular changes you've made (git add -p, for example). So I'm not sure what you're talking about in your last sentence.
Re: (Score:2)
My main issue with Git was it's Unicode filename support under Windows. Quite frankly it's broken. You add and commit your "Unicode Filenames" fine in Linux or Windows, but if you ever check them out under Windows they are renamed to a weird character set and require being re-added and checked in with their new path.
SVN doesn't have this problem (using TortoiseGit and mSysGit vs TortoiseSVN). I stopped using Git after I encountered this and have reverted to using Subversion until this has been resolved. If
Re: (Score:2)
Even as a non english speaker, I must say, don't name your filenames outside of the usual ascii range. I have yet to encounter a software project where this is handled otherwise.
If you drop the average users in things become different though, but those cannot cope with git anyway.
Re: (Score:2)
Well DVCs systems are different, I use CVS, SVN, and GIT day in day out, you have to work in DVCS systems differently. In SVN you have your commits thats it. In DVCs systems your commits are local and there you have control and the push is global.
So the push is more or less the final straw you have to do.
Coming from SVN you have to unlearn certain stuff.
Gits nasty side is its quirky command line, coming from SVN Mercurials workflow (which also can be built on top of Git but is not the recommended way) might
Re: (Score:2)
Then, what if you only want to push/commit parts of the change you made in a given file then ? The foundation of the problem you mentioned seems unsolvable.
I would say that ultimately it depends on how you organize your work. One way to organize your work would be to create branches for changes you make with each branch specific to a given bug report, change request or what not. The problem in your view would be that you will still need to merge anyways.
I think merging and branches end up being a must in m
Re: (Score:2)
Then you're doing it wrong. You don't commit half of the files you want to push... you only commit the files you want to push, and then if you want to commit the others but not push them then you commit those separately, and only push the commit that you wanted to get to other repositories.
However, I do admit that it seems that Git is harder to use than SVN, from my experience with working with a team of about 10 developers who were new to Git but not SVN: they have failed at doing what shouldn't be hard.
Re: (Score:2)
He's talking about doing a "git push" of some subset of files, not what git calls a commit.
Re: (Score:2)
Then don't commit stuff to a branch you intend to push? Seems pretty straightforward to me...
Re: (Score:3)
Try using carat (^) in a recent SVN client. If you're in a working directory, it's a stand-in for the base repository URL. so svn+ssh://foo.bar.biz/svn/widget/trunk could be written as: ^/trunk
Re: (Score:2)
Actually SVN has another amazing thing, you can change configurations of your project on the server centrally without filling your servers hds. You have a project 15 dependencies which change over time, simply either use svn:external, or copy them in. The next time the users do an svn:update they get all source dependencies in.
Also don't underestimate the power of the webdav support for the average user, they simply can drop the documents into their remote folders and have them versioned.
So SVN is not that
Re: (Score:3)
I wasn't talking about the command line. The command line is probably roughly equal, annoying wise that is..
I'm talking abou the GUI tools that are currently available. They suck, and doing tasks like cherry picking files is a pain in the but. Of course, the fact that there's a term called "Cherry Pick Commit" that has nothing to do with "Cherry picking" files for commit.. might be part of the reason... You are right, though.. not having to checkin all files in one command is nice.
My beefs with GIT inclu
Re: (Score:2)
I'm talking abou the GUI tools that are currently available. They suck, and doing tasks like cherry picking files is a pain in the but. Of course, the fact that there's a term called "Cherry Pick Commit" that has nothing to do with "Cherry picking" files for commit.. might be part of the reason... You are right, though.. not having to checkin all files in one command is nice.
So I can't speak to GUI tools on anything but Windows, but there's a TortoiseGit that functions nearly identically to TortiseSVN. It e
try SmartGit (Score:3)
I find SmartGit [syntevo.com] more useful for day-to-day stuff.
I have TurtoiseGit installed (and it works) but i never use it. Having the correct icons show up in Explorer is nice though.
Re: (Score:2)
(2) You can't check out just a subtree of a Git repository. This actually has cost me quite a lot of time when I had to take a repository that I later figure out was too big and split it up.
I HATED this shit with SVN, I wanted to check out the entire repository but it was just too big, so I could only check out parts of it. Now, with Git, I've changed to where I love the fact that I have everything on my local storage.
What I think is that the reason repositories were so big in the first place was because CVS/SVN encouraged it. With Git, if a repository is too big and you want to split it up, then the repository shouldn't have been so big in the first place! If bet that if there were never a
Re: (Score:2)
Exactly who the fuck has 50GB in one source code tree?
--
BMO
Data, Images, Binary builds etc. (Score:5, Informative)
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.
Re:Data, Images, Binary builds etc. (Score:4, Informative)
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: (Score:2)
Re:Data, Images, Binary builds etc. (Score:4, Insightful)
Storing large volumes of binary data in an archived fashion is a job for a filesystem, not a CVS. A CVS is not intended as a backup solution, nor should it be used as such.
So when I want to release a critical patch to an old version of our software I shouldn't just be able to extract everything from the repo, make the change and build the release installer, I should also have to find where any required binary files for that release were stored and copy them to my machine and hope that no-one deleted them in the meantime?
I really know very little about git, but from the numerous 'Git doesn't do X, Y, Z', 'But you shouldn't be doing X, Y, or Z!' posts here I don't see a reason why I would I want to.
Re: (Score:2)
You are a lazy shit, Use the right tools and partition correctly..
...and you are an anonymous coward. Now please let the grownups speak.
Not everyone get to start at the start of a project or determine the team's tools, build process or repository structure.
Re: (Score:2)
Usually less so than the code, actually. If somebody is embedding an image into source code, 99% of the time, it's an icon or some other rarely updated graphic. If somebody is updating an image regularly, odds are they'll have the app pull that image from a web server and cache it somewhere, in which case it wouldn't live in the DVCS (unless your website does).
Re:Data, Images, Binary builds etc. (Score:4, Insightful)
and you've just screwed the entire configuration process there.
The whole point of a SCM is that you put your sources in there so you can check it out and get the same set of sources from any point in history. The moment you say "oh that's too big, we'll put it somewhere else" is the day you lose control of that reproducability.
Your images used in the app are part of the source. While there's a place for storing data elsewhere, it still has to be controlled in a way that you can get it back out again for a particular version.
Re: (Score:2)
Re: (Score:2)
Re:It's because (Score:4, Informative)
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.
Re: (Score:2)
What's the problem with 150+ repos? What's hard to manage? How is that any harder than managing 150+ separate projects (which you have to do anyway no matter what VCS you use)?
Re:It's because (Score:4, Informative)
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: (Score:2)
With git, you have no option BUT to pull the entire repository, and all of its data, and all of its history.
Re:It's because (Score:5, Informative)
see "git clone --depth" [die.net]
Re:It's because (Score:4, Informative)
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: (Score:2)
Actually the repo handling is really SVNs strong side, unsurpassed by newer systems.
Externals are extremely powerful so is the simply copy paste algorithm (which internally makes hard links)
to chain together cross project source dependencies.
Git and others cannot follow that route due to their different way to treat things.
For git the server is more or less the dump to dump the files to, while for svn this is the filesystem
and the local stuff is just a small copy of what is going on on the server.
Re: (Score:3)
Well, you should post with your real name if you are going to make such an encompassing statement, instead of anonymously. I'm kinda wondering what repo management tools you are using that can handle 50GB+ data sets that you are trying to compare against something like git?
From my experience handling large data sets is less a function of the repo and more a function of disk bandwidth and memory. Putting, say, a million files into a repo (any repo) is not a big deal but managing it will definitely be depen
Re: (Score:3)
Well, I certainly was not expecting you to use RCS as a comparison point. RCS is utterly horrible when dealing with large data sets. Any modification to a file requires rewriting the entire rcs file and doing something like, oh, tagging, requires rewriting every single file in the repo. Every single one.
RCS is a very filesystem-heavy repo management system. Updates, checkouts, pretty much everything you do *except* single-file log displays are expensive. Such operations have to scan or access nearly ev
Re: (Score:2)
I use Git on my project which has only one developer (me, of course). I can't imagine working without source control.
Re: (Score:2)
You have a small project/sprint? Just cp your source code periodically (or rsync).
Never, ever, again, no. Whatever I code, big or small, it ends up in SVN or GIT. Never again will I be searching files for older revisions, and I can't understand how some people can handle professional projects without it.
Re:Mercurial (Score:4, Interesting)
Mercurial is not really superior, it is a subset of about 80% of hits functionality baked into a nicer command line set. Btw. Mercurials strong side is really the relatively clean command line outside of that both systems are so close it is eery.
Re: (Score:2)
In what way is Mercurial better than git?
I use both extensively, but getting the equivalent functionality of git in Mercurial means using several extensions, most of which aren't as good as their git originals.
There are three or four branching extensions for mercurial, and none matches what basic git branches do with the same ease of use. It's as if the developers didn't want to admit that git got it right, and so they stopped short of also making something that works.
I believe git is more popular simply be
Re:Mercurial (Score:5, Insightful)
Mercurial's most touted advantage is that it's easier to learn, but this is a joke. If you develop, you interact with the version control system all day. A tiny advantage in learning it faster is nothing compared to not being able what you want to do afterwards, or having to redo something because the version control works against you instead of with you.
I work at a company that has used Git professionally. My team isn't dumb people, but they have fucked up with Git dozens of times. What I quoted is an okay argument at a personal level. However, there is something to be said as an organization that having an easy-to-use tools is better.
I am not making the argument that either Mercurial or Git is better; I am making the argument that tools which are easier to use will lead to less fuck-ups in an organization.
Re: (Score:3)
Meh, call me when there's tortoisegit, and by then it will be too late.
You missed the call, it was a while ago. I considered TortoiseGit [google.com] mature enough to use around V1.3, which was January of 2010. The upward spike in downloads shown on their page, which really took off around V1.2, shows quite a few people agree.
Re: (Score:3)
In Eclipse you now also have top tier support for Git through the EGit plugin. This is sitting over a pure Java implementation of git called JGit (i.e. no need for msysgit). It works pretty well and in the manner you would expect if you've ever used a VCS