It's more a proxy for economic situation. Poor people tend to vote for people who want to improve their situation, rich people tend to vote for people who want to improve their situation. It's just that the majority of blacks are relatively poor (or their parents were) and see more benefit from Democrats, whereas white people tend to dominate the demographics that benefit from Republican policies.
I've heard statistics from some sources as high as 97% of black voters will be voting for Obama, just google for some of it it's out there. Even if they're off and lets say it's only 85%, still.
If 85% of white people voted for McCain, it would be considered racist.
It would only be racist if they vote for him only because he's white. So why is black people voting for Obama different? Exactly because there's never been a black president yet. So far, the presidency has always been reserved for a white elite. People want to believe that skin colour has nothing to do with your ability to become president, and having a president with a different skin colour would be the ultimate proof of that.
Had I been allowed to vote, this would definitely be a factor for me (although I'm as white, blond haired and blue eyed as you can get), although it's a lot easier to say this about someone who is smart, collected and rational. I wouldn't have been as eager to vote for Jesse Jackson, for example.
(Obama isn't even all that black; he's half white, raised by white mother and grandparents, and even his father doesn't have Afro-American roots. Even so, I have little doubt his presidency would open a lot of doors.)
And more generally: how to safely stash away my incomplete code in a branch so it won't show up in version history, without throwing in away my hard work completely. And also how undo (and safely stash away) my recent change that conflicts with a really big pull, in order to get git to merge automatically rather than have me do it by hand.
None of it is hard once you know it, but it's not trivial or intuitive either. It is in the man pages, and you may need to experiment a bit in order to figure out what the man pages mean, because documentation, while present, is not great.
But Americans have been hearing for around two centuries now from Europeans that we don't give enough deference to our betters. My favorite example being Alexis de Tocqueville lamenting that "ordinary citizens" had too much voice in politics and society, meaning the "elites" didn't get their proper due. This attitude of "listen to your betters, and we'll tell you WHO those betters are" is a distinctly European one.
I thought it's mostly a US attitude that you shouldn't criticise your betters while they're fucking up and leading you into a stupid war. Because that was the dominant attitude 5 years ago.
Besides, De Tocqueville has been dead for quite some time now.
As a european citizen, I beg to differ. Euro? Maybe.
Really? His bio doesn't mention where he's born, but he seems to operate mostly in the US. Also, his "things have to cost money, and people will die without it" attitude sounds much more American than European to my ears.
OK, so I was being a bit facetious, but speaking as devil's advocate, free stuff in a recession could theoretically damage the profitability of software houses, meaning that there aren't as many jobs for programmers.
Consider, for example, that your supplier goes bust (due to the recession). Do you migrate to another closed system, or to an open one? Do you risk your next supplier folding and you having to move again?
But most people won't realise the threat this poses....
But that's a threat to closed source, right? Not to open source. You're saying that not only will supply of open source be bigger, so will demand.
No. I'm assuming they ARE employed, and about to get laid-off due to the recession. Therefore they might not be able to pay their bills, and their priority will be survival, not opensource programming.
But the open source programmers will be the first to find a new job. Open source projects look mazingly good on your resume, and respected committers tend to have lots of useful contacts, a reputation and provable programming skills.
(devil's advocate): maybe everyone will -use- open source projects (cutting costs), but nobody talented would contribute to them without compensation (again, cutting costs).
Talented people will work on whatever they want, and will manage to get paid for it (or for something else that doesn't take up all of their time). This is how open source got started.
This is really useful when some people are committing crazy shit
This isn't a technology problem, it's a social problem. To solve this, you actually TALK to the developer in question and tell him to stop committing crazy shit. If he has a problem with that, you revoke his commit access and require he submit patches to you for review.
That may prevent a valuable developer from contributing in the future, but in the mean time you're still stuck with crazy shit.
Git gives you the tools to solve this problem.
Not only is that roughly the same amount of work
What exactly is the same amount of work here? Blocking development compared to fixing a problem?
(the main difference being that, instead of pulling from someone, you have to wait until the out-of-band push to you), but you teach someone an important lesson: how not to be an asshole in a group collaboration setting.
You assume only assholes commit bad code. Good programmers can fuck up too.
I'm getting the impression that for SVN the world consists only of assholes and perfect programmers. I think the majority of programmers are neither. You need to be able to recover from mistakes, not blindly hope they don't happen and cripple your business when they do.
But even then, it's hard to fuck up git, and easy to fuck up SVN.
Really? Seems the opposite to me. You can very easily wipe out large amounts of local history with git, and if you haven't pushed it elsewhere, it's gone, forever. Git's tools and poor documentation make it easy to shoot yourself in the foot. With SVN, after you commit, your changes are pretty much immortalized without direct repository editing on the server.
You're comparing apples and oranges here: a situation where you go out of your way to destroy git history with one where you go out of your way not to mess up SVN. Not pushing git commits to another machine is comparable to never commiting anything in SVN. If you lose your local machine, you're fucked.
On the other hand, in SVN it's actually quite easy to edit the repository by hand and destroy stuff. With git, at the very least, you know it's been messed with because the hash codes are wrong.
Granted, it's sorta the same -- with both git and svn you can lose data if you don't push/commit to another location -- but git more or less encourages you *not* to push anywhere until/unless you need to, and provides a host of potentially 'dangerous' tools that work on your local repository that svn doesn't provide.
I don't see how git encourages you not to push. With SVN, pushing incomplete code to the trunk may fuck up other people's work. With git, you can always push to your own github space and merge that into the central repository when it's finished.
Just learning to use git, I just did something I'm personally amazingly impressed by:
I was writing a new (small) feature for our website. I'd found an interesting solution, and implemented the first part of it, and put it in a commit. Then my boss (correctly) decides that perhaps this feature isn't such a good idea after all, and other stuff it more urgent.
I like my code, so I don't want to throw it away. But I don't want to push it to the central repository either. So here's what I do:
Branch (which is currently exactly the same as the master, including that last commit). In master, revert that last commit. A revert is a new commit that undoes an old one (and it can be very old). 'git show-branch' shows my master to be based on the branch (because the master's graph contains the branch's HEAD).
If I were to push my master now, the central repository would show two commits, the second of which undoes the first. I'd rather have the new feature just in the branch, and not in the repository's master at all. So I try something else instead. And here is where we're going to reverse causality:
Using 'git reset --soft branchname^', I reset the master to the state before the last commit in the branch. I keep my local uncommitted changes, but the last two commits (the new feature and the revert of it) are gone from my master. This is what I want to push to the central repository.
So where's the magic? 'git show-branch' suddenly shows that my branch is now based on the master, when it was the other way around a moment ago. But now the branch is ahead by one commit, so technically it's correct.
I'll now continue to commit in my master, and if we ever decide what to do with the new feature, I can easily merge the branch back into the master and continue from there.
what i saw as a large svn strength - ability to checkout only parts of a repository. imagine a repository that has several large directories, but most users would ever want only one.
In git you'd have to make these several different projects, I guess. And I think you can have another project include all of these so the people who want everything can get everything, but I've never done that.
I agree that this seems to be one SVN feature that git lacks, and I used it a lot when I was still using SVN. On the other hand, the main reason I used it is because checking out and synchronising large projects could get pretty slow. Git is much faster (on unix at least), so that reason may not be very relevant anymore.
also, git seems to be very, very source code centric - it was even mentioned that changing a binary file a bit (like slightly changing an image) can make it's history split because git wouldn't recognise it as the same file.
Could be. Binaries are definitely a bit trickier. To get git to handle them the same way it handles source files, you'd need proper diff tools for binaries, and considering some binaries use a lot of compression, I'm not sure that can ever work.
If you want, you can treat git the same as svn and not change your workflow. Then you can let others who want to commit locally work differently.
This is I think possibly one of gits biggest strengths: it doesn't force you to work in a particular way. It supports lots of powerful weird stuff, but you can ignore it if you like.
You have your local repository with your local branch, but if you really want, you can write a simple script that does git-add, git-commit and git-push with a single command, and suddenly it's nearly indistinguishable from your basic SVN workflow. Only branching is really different, I think, but if you're branching anyway, that just adds more reasons to use git.
I've found Subclipse over the past 6 months I've used it to be flawless and combined with Eclipse makes VS look like a toy.
Maybe there's a better version out. My problem with subclipse is that when I copy or rename a directory, it keeps its old.svn folders, which fucks up the the source control. When I copy a directory from one project to another, it sometimes(?) keeps synchronising with the old project instead of the new one.
This is by far my biggest issue with subclipse, although I've had many others. And I'm not sure Subversive doesn't have the same problem (although it fixes some of the other issues, I think).
That may work fine when you're the only one working on the code, but if you're working with someone else, and he's committed code that you don't think is any good (or at least not ready for production yet), but later commits from you are, then with a single trunk you're simply out of luck.
This is back to my original point. If I'm working with people who are regularly checking in bad code,
I'm not talking about one person regularly checking in bad code. I'm talking about one person doing it once. And who hasn't checked in something that wasn't quite finished at least once?
Even if it happens once, in SVN you have to undo it by hand. In git you simply revert the bad commit.
Why would I let him go on doing dumb things any longer than necessary?
It's not about one person doing dumb things constantly, it's about everybody making mistakes every once in a while. I don't believe for a minute in perfect, flawless programmers.
But what if you've been working on something that seemed like a good idea at the time, and suddenly you realise you're going completely in the wrong direction and need to undo a lot of commits (but you want to keep the other bugfixes you did)? Or what if someone else is working on the same project?
I mainly solve this by making sure it doesn't happen much.
Not much, but it may happen sometimes. Unless you're perfect or psychic.
Branching can only save you if you realize it's a bad idea before you merge to trunk, only if your changes are mostly bad.
No, branching will save you every time if you branch every time. While explicit branches are used (and easy) in git, you might actually consider every single commit a branch of its own, that's immediately merged into the trunk.
I think the solution to bad ideas is better product management, not better version control.
I think the solution to bad implementation is to make sure you can fix it easily. Can you really honestly say you've never written any code that did more harm than good?
Let's take a simple example. Me and my team are developing against trunk, committing every few hours, and shipping weekly. How many relevant versions of the software are there?
I count 2.
I count 2 + one for each developer.
One's in production, and one's at the head of the trunk. The divergence between the two is at maximum, however much the team can develop in a week.
Now I branch. How many interesting versions are there? I count 3. How much divergence is there? Well, there's release to head, release to branch, and branch to head.
So that's 2 versions with 1 axis of divergence, versus 3 versions with 3 axes of divergence.
No matter how you measure it, that is increased complexity.
In git, each branch is simply a big pile of commits that are easily merged. Divergence only matters when two specific commits conflict with each other. So branches don't add any more complexity than commits do. A bit maybe, but git makes this quite managable.
Now try to have two programmers work on an big new feature while the rest works on bugfixes, still all in the same trunk. Release day comes, and the new feature isn't finished. Suddenly you've got a lot of complexity on your hands that could have easily been solved by putting this in a separate branch.
Subversion is built around the notion that you meant to do that. Someone checked in their entire hard drive to the repository by mistake? they meant to do that!
Some guy in India actually did (almost) that. He checked his My Documents folder into our SVN repository.
I think the only time git doesn't know how to merge is when two developers have changed the exact same line of code. That sort of thing always requires human judgement, but git comes with a host of merge tools that will help you. However, when people commit (and push) regularly, git will usually figure it out on its own without ever bothering you with something as trivial as merging code.
Git can also deal with refactoring and moving code to different locations in the project.
I just spent a couple years at a job where I used svn exclusively, and I loved it right up until the moment I started working with git.
I have exactly the same thing. I hadn't even heard of git three weeks ago (when I started at a new job), and while the bugs in SVN front-ends were annoying, I'd learned to work around them.
The first feature of any source control system that matters is "reliable". A source control shall not loose source code. No exceptions.
The biggest part of "reliable" comes from being "idiot proof". There should be nothing that any of my fresh-out new hires can do that can cause loss of code. And, teaching a new hire how to make a working branch and populate a project should only take a few minutes.
Central backup is also a big part of "reliabile". If there is only ONE disk/filesystem that has to be backed up, we can mirror it and journal it, and back it up every night, with no problem at all.
So far, it looks like git is a perfect fit for you. Much better than SVN, which, while easier to understand, does allow idiots to fuck up your code.
Code maturity is the third big component of "reliable". A source-control system that has been around for less than a decade might still have some important bugs.
A source-control system that has been around for more than a decade can also have important bugs. And a younger system doesn't necessarily have bugs. Git is pretty reliable despite its youth.
Last year I nearly had to murder somebody because he was pushing git for 6 guys in the same office producing a web site that released weekly. I agreed that git was cool, and were I doing a distributed project, especially an open-source one, I'd love to use it. But I just couldn't see the value for a bunch of guys who worked off of trunk, were on the same LAN, had exactly one version in production, and checked in between a few times a day and a couple times a week.
If people feel there is a value for a team in that situation, let me know, as I'd love to hear about it.
We're in exactly the same situation, and have recently become convinced of the superiority of git. I didn't even know git until 3 weeks ago (when I started working here), but now I'm a believer.
Ofcourse there's also a disadvantage to using git: you have to be a genius to understand how it works. SVN is far easier to understand. But even then, it's hard to fuck up git, and easy to fuck up SVN.
Read some of my other comments here for more details.
Slashdot Mirror
Yeah! And I just like to vote for whoever looks stupider!
And I know from personal experience that handsome people are smarter.
So political party becomes a proxy for race,
It's more a proxy for economic situation. Poor people tend to vote for people who want to improve their situation, rich people tend to vote for people who want to improve their situation. It's just that the majority of blacks are relatively poor (or their parents were) and see more benefit from Democrats, whereas white people tend to dominate the demographics that benefit from Republican policies.
I've heard statistics from some sources as high as 97% of black voters will be voting for Obama, just google for some of it it's out there. Even if they're off and lets say it's only 85%, still.
If 85% of white people voted for McCain, it would be considered racist.
It would only be racist if they vote for him only because he's white. So why is black people voting for Obama different? Exactly because there's never been a black president yet. So far, the presidency has always been reserved for a white elite. People want to believe that skin colour has nothing to do with your ability to become president, and having a president with a different skin colour would be the ultimate proof of that.
Had I been allowed to vote, this would definitely be a factor for me (although I'm as white, blond haired and blue eyed as you can get), although it's a lot easier to say this about someone who is smart, collected and rational. I wouldn't have been as eager to vote for Jesse Jackson, for example.
(Obama isn't even all that black; he's half white, raised by white mother and grandparents, and even his father doesn't have Afro-American roots. Even so, I have little doubt his presidency would open a lot of doors.)
Well, today I got to learn:
And more generally: how to safely stash away my incomplete code in a branch so it won't show up in version history, without throwing in away my hard work completely. And also how undo (and safely stash away) my recent change that conflicts with a really big pull, in order to get git to merge automatically rather than have me do it by hand.
None of it is hard once you know it, but it's not trivial or intuitive either. It is in the man pages, and you may need to experiment a bit in order to figure out what the man pages mean, because documentation, while present, is not great.
But Americans have been hearing for around two centuries now from Europeans that we don't give enough deference to our betters. My favorite example being Alexis de Tocqueville lamenting that "ordinary citizens" had too much voice in politics and society, meaning the "elites" didn't get their proper due. This attitude of "listen to your betters, and we'll tell you WHO those betters are" is a distinctly European one.
I thought it's mostly a US attitude that you shouldn't criticise your betters while they're fucking up and leading you into a stupid war. Because that was the dominant attitude 5 years ago.
Besides, De Tocqueville has been dead for quite some time now.
As a european citizen, I beg to differ. Euro? Maybe.
Really? His bio doesn't mention where he's born, but he seems to operate mostly in the US. Also, his "things have to cost money, and people will die without it" attitude sounds much more American than European to my ears.
He's a US snob.
OK, so I was being a bit facetious, but speaking as devil's advocate, free stuff in a recession could theoretically damage the profitability of software houses, meaning that there aren't as many jobs for programmers.
Consider, for example, that your supplier goes bust (due to the recession). Do you migrate to another closed system, or to an open one? Do you risk your next supplier folding and you having to move again?
But most people won't realise the threat this poses....
But that's a threat to closed source, right? Not to open source. You're saying that not only will supply of open source be bigger, so will demand.
This guy is under the assumption everyone who works on open source technology is after financial gain. Very short sighted
It's worse. The guy is assumed everyone who works on open source is after financial gain and not getting it. The author is an idiot.
Um... this isn't a US downturn. This is a global recession. Please spend five minutes investigating this before you pie in the sky comment.
It's only a recession when economic growth is negative. So far, it's just a downturn.
Okay, maybe it's a US recession and a global downturn. Would that be an acceptable compromise?
I agree. I just read some of this tripe and I'd like to punch this guy right in his arrogant face.
What, for free? That's valuable labor!
Alright, I'm willing to pay GP $1 to punch the guy in his arrogant face. Would that be okay?
No. I'm assuming they ARE employed, and about to get laid-off due to the recession. Therefore they might not be able to pay their bills, and their priority will be survival, not opensource programming.
But the open source programmers will be the first to find a new job. Open source projects look mazingly good on your resume, and respected committers tend to have lots of useful contacts, a reputation and provable programming skills.
(devil's advocate): maybe everyone will -use- open source projects (cutting costs), but nobody talented would contribute to them without compensation (again, cutting costs).
Talented people will work on whatever they want, and will manage to get paid for it (or for something else that doesn't take up all of their time). This is how open source got started.
He just doesn't get that some people do things not for the money.
Even worse, he doesn't get that a lot of open source programmers are programming for money.
He doesn't understand the open source economy at all. "Free labour" has nothing to do with it.
This is really useful when some people are committing crazy shit
This isn't a technology problem, it's a social problem. To solve this, you actually TALK to the developer in question and tell him to stop committing crazy shit. If he has a problem with that, you revoke his commit access and require he submit patches to you for review.
That may prevent a valuable developer from contributing in the future, but in the mean time you're still stuck with crazy shit.
Git gives you the tools to solve this problem.
Not only is that roughly the same amount of work
What exactly is the same amount of work here? Blocking development compared to fixing a problem?
(the main difference being that, instead of pulling from someone, you have to wait until the out-of-band push to you), but you teach someone an important lesson: how not to be an asshole in a group collaboration setting.
You assume only assholes commit bad code. Good programmers can fuck up too.
I'm getting the impression that for SVN the world consists only of assholes and perfect programmers. I think the majority of programmers are neither. You need to be able to recover from mistakes, not blindly hope they don't happen and cripple your business when they do.
But even then, it's hard to fuck up git, and easy to fuck up SVN.
Really? Seems the opposite to me. You can very easily wipe out large amounts of local history with git, and if you haven't pushed it elsewhere, it's gone, forever. Git's tools and poor documentation make it easy to shoot yourself in the foot. With SVN, after you commit, your changes are pretty much immortalized without direct repository editing on the server.
You're comparing apples and oranges here: a situation where you go out of your way to destroy git history with one where you go out of your way not to mess up SVN. Not pushing git commits to another machine is comparable to never commiting anything in SVN. If you lose your local machine, you're fucked.
On the other hand, in SVN it's actually quite easy to edit the repository by hand and destroy stuff. With git, at the very least, you know it's been messed with because the hash codes are wrong.
Granted, it's sorta the same -- with both git and svn you can lose data if you don't push/commit to another location -- but git more or less encourages you *not* to push anywhere until/unless you need to, and provides a host of potentially 'dangerous' tools that work on your local repository that svn doesn't provide.
I don't see how git encourages you not to push. With SVN, pushing incomplete code to the trunk may fuck up other people's work. With git, you can always push to your own github space and merge that into the central repository when it's finished.
Just learning to use git, I just did something I'm personally amazingly impressed by:
I was writing a new (small) feature for our website. I'd found an interesting solution, and implemented the first part of it, and put it in a commit. Then my boss (correctly) decides that perhaps this feature isn't such a good idea after all, and other stuff it more urgent.
I like my code, so I don't want to throw it away. But I don't want to push it to the central repository either. So here's what I do:
Branch (which is currently exactly the same as the master, including that last commit).
In master, revert that last commit. A revert is a new commit that undoes an old one (and it can be very old). 'git show-branch' shows my master to be based on the branch (because the master's graph contains the branch's HEAD).
If I were to push my master now, the central repository would show two commits, the second of which undoes the first. I'd rather have the new feature just in the branch, and not in the repository's master at all. So I try something else instead. And here is where we're going to reverse causality:
Using 'git reset --soft branchname^', I reset the master to the state before the last commit in the branch. I keep my local uncommitted changes, but the last two commits (the new feature and the revert of it) are gone from my master. This is what I want to push to the central repository.
So where's the magic? 'git show-branch' suddenly shows that my branch is now based on the master, when it was the other way around a moment ago. But now the branch is ahead by one commit, so technically it's correct.
I'll now continue to commit in my master, and if we ever decide what to do with the new feature, I can easily merge the branch back into the master and continue from there.
what i saw as a large svn strength - ability to checkout only parts of a repository. imagine a repository that has several large directories, but most users would ever want only one.
In git you'd have to make these several different projects, I guess. And I think you can have another project include all of these so the people who want everything can get everything, but I've never done that.
I agree that this seems to be one SVN feature that git lacks, and I used it a lot when I was still using SVN. On the other hand, the main reason I used it is because checking out and synchronising large projects could get pretty slow. Git is much faster (on unix at least), so that reason may not be very relevant anymore.
also, git seems to be very, very source code centric - it was even mentioned that changing a binary file a bit (like slightly changing an image) can make it's history split because git wouldn't recognise it as the same file.
Could be. Binaries are definitely a bit trickier.
To get git to handle them the same way it handles source files, you'd need proper diff tools for binaries, and considering some binaries use a lot of compression, I'm not sure that can ever work.
If you want, you can treat git the same as svn and not change your workflow. Then you can let others who want to commit locally work differently.
This is I think possibly one of gits biggest strengths: it doesn't force you to work in a particular way. It supports lots of powerful weird stuff, but you can ignore it if you like.
You have your local repository with your local branch, but if you really want, you can write a simple script that does git-add, git-commit and git-push with a single command, and suddenly it's nearly indistinguishable from your basic SVN workflow. Only branching is really different, I think, but if you're branching anyway, that just adds more reasons to use git.
I've found Subclipse over the past 6 months I've used it to be flawless and combined with Eclipse makes VS look like a toy.
Maybe there's a better version out. My problem with subclipse is that when I copy or rename a directory, it keeps its old .svn folders, which fucks up the the source control. When I copy a directory from one project to another, it sometimes(?) keeps synchronising with the old project instead of the new one.
This is by far my biggest issue with subclipse, although I've had many others. And I'm not sure Subversive doesn't have the same problem (although it fixes some of the other issues, I think).
That may work fine when you're the only one working on the code, but if you're working with someone else, and he's committed code that you don't think is any good (or at least not ready for production yet), but later commits from you are, then with a single trunk you're simply out of luck.
This is back to my original point. If I'm working with people who are regularly checking in bad code,
I'm not talking about one person regularly checking in bad code. I'm talking about one person doing it once. And who hasn't checked in something that wasn't quite finished at least once?
Even if it happens once, in SVN you have to undo it by hand. In git you simply revert the bad commit.
Why would I let him go on doing dumb things any longer than necessary?
It's not about one person doing dumb things constantly, it's about everybody making mistakes every once in a while. I don't believe for a minute in perfect, flawless programmers.
But what if you've been working on something that seemed like a good idea at the time, and suddenly you realise you're going completely in the wrong direction and need to undo a lot of commits (but you want to keep the other bugfixes you did)? Or what if someone else is working on the same project?
I mainly solve this by making sure it doesn't happen much.
Not much, but it may happen sometimes. Unless you're perfect or psychic.
Branching can only save you if you realize it's a bad idea before you merge to trunk, only if your changes are mostly bad.
No, branching will save you every time if you branch every time. While explicit branches are used (and easy) in git, you might actually consider every single commit a branch of its own, that's immediately merged into the trunk.
I think the solution to bad ideas is better product management, not better version control.
I think the solution to bad implementation is to make sure you can fix it easily. Can you really honestly say you've never written any code that did more harm than good?
Let's take a simple example. Me and my team are developing against trunk, committing every few hours, and shipping weekly. How many relevant versions of the software are there?
I count 2.
I count 2 + one for each developer.
One's in production, and one's at the head of the trunk. The divergence between the two is at maximum, however much the team can develop in a week.
Now I branch. How many interesting versions are there? I count 3. How much divergence is there? Well, there's release to head, release to branch, and branch to head.
So that's 2 versions with 1 axis of divergence, versus 3 versions with 3 axes of divergence.
No matter how you measure it, that is increased complexity.
In git, each branch is simply a big pile of commits that are easily merged. Divergence only matters when two specific commits conflict with each other. So branches don't add any more complexity than commits do. A bit maybe, but git makes this quite managable.
Now try to have two programmers work on an big new feature while the rest works on bugfixes, still all in the same trunk. Release day comes, and the new feature isn't finished. Suddenly you've got a lot of complexity on your hands that could have easily been solved by putting this in a separate branch.
Subversion is built around the notion that you meant to do that. Someone checked in their entire hard drive to the repository by mistake? they meant to do that!
Some guy in India actually did (almost) that. He checked his My Documents folder into our SVN repository.
Is merging really any easier with git?
It's trivial. Git merges everything automatically.
I think the only time git doesn't know how to merge is when two developers have changed the exact same line of code. That sort of thing always requires human judgement, but git comes with a host of merge tools that will help you. However, when people commit (and push) regularly, git will usually figure it out on its own without ever bothering you with something as trivial as merging code.
Git can also deal with refactoring and moving code to different locations in the project.
I just spent a couple years at a job where I used svn exclusively, and I loved it right up until the moment I started working with git.
I have exactly the same thing. I hadn't even heard of git three weeks ago (when I started at a new job), and while the bugs in SVN front-ends were annoying, I'd learned to work around them.
But now I really truly love git. And github.
The first feature of any source control system that matters is "reliable". A source control shall not loose source code. No exceptions.
The biggest part of "reliable" comes from being "idiot proof". There should be nothing that any of my fresh-out new hires can do that can cause loss of code. And, teaching a new hire how to make a working branch and populate a project should only take a few minutes.
Central backup is also a big part of "reliabile". If there is only ONE disk/filesystem that has to be backed up, we can mirror it and journal it, and back it up every night, with no problem at all.
So far, it looks like git is a perfect fit for you. Much better than SVN, which, while easier to understand, does allow idiots to fuck up your code.
Code maturity is the third big component of "reliable". A source-control system that has been around for less than a decade might still have some important bugs.
A source-control system that has been around for more than a decade can also have important bugs. And a younger system doesn't necessarily have bugs. Git is pretty reliable despite its youth.
Last year I nearly had to murder somebody because he was pushing git for 6 guys in the same office producing a web site that released weekly. I agreed that git was cool, and were I doing a distributed project, especially an open-source one, I'd love to use it. But I just couldn't see the value for a bunch of guys who worked off of trunk, were on the same LAN, had exactly one version in production, and checked in between a few times a day and a couple times a week.
If people feel there is a value for a team in that situation, let me know, as I'd love to hear about it.
We're in exactly the same situation, and have recently become convinced of the superiority of git. I didn't even know git until 3 weeks ago (when I started working here), but now I'm a believer.
Ofcourse there's also a disadvantage to using git: you have to be a genius to understand how it works. SVN is far easier to understand. But even then, it's hard to fuck up git, and easy to fuck up SVN.
Read some of my other comments here for more details.