Why is Git better than Subversion?
stackoverflow.com
stackoverflow.com
I like git fine, but judging quality by where the crowd is running is like flipping a coin.
edit: Fine. We're just going to substitute pith for basic reason here, I guess. Because the industry has largely moved to git, it's clearly the superior tool, and those who don't accept that are clearly emotionally blocked. Or not.
Interestingly enough, in the 'Open Source projects and poisonous people' talk[1] with two SVN developers, they mention how they chose that line specifically to make sure that everybody is on the same page with the scope of the project - improving upon what people knew and were used to instead of wild, new things. Specifically because they would often have people come into the community with some grand plans that would have just exploded the scope.
It is of course arguable to what extent there could be a general rule to this, but in this case, GIT is just so fundamentally and obviously the better option than SVN. Had somebody tried to make SVN into GIT, it would have simply killed SVN, so it was the right course of action to make it a new project. SVN was destined to die by its design.
To see the GIT adoption rates these days (particularly due to tools like GitHub) is very encouraging to people who like to think that sometimes, starting over fresh is the only option. Of course, the thing you want to build really has to be that much better than the old thing you're trying to replace.
So I agree with you - it's alright to say that GIT is better than SVN. The crucial point to me, though, is that it is so much better. So much better that it is worth the effor to build and worth the effort of the community to switch.
[0] https://www.youtube.com/watch?v=4XpnKHJAok8 [1] https://www.youtube.com/watch?v=-F-3E8pyjFo
Having experienced the workflow they learned from using another DVCS (Bitkeeper) probably also influenced his decision at the time.
How about they make a dedicated space in SO where this kind of questions are allowed.
I don't mean a free for all, but a heavily moderated part where you can ask recommendations from your peers about the best framework / book etc as long as it's related to programming.
Edit: Although it would be great if SO suggested moving discussions there, instead of just closing as off-topic. You can close-move questions that belong to superuser.com for example.
Here's what they say :
Don't ask about...
1) general workplace issues, office politics, etc.
2) implementation issues or programming tools
3) Anything not directly related to software development
4) Questions that are primarily opinion-based
5) Questions with too many possible answers or that would require an extremely long answer
I need 2, 4 and 5 to be able to ask "what's the best web stack for [my use case]" ...
The distinction seems clear from 60,000 feet but sorting edge cases seems to depend largely on capricious and arbitrary moderation. And practically speaking, in many cases you would actually get better answers on stackoverflow, but for the oppressive moderation.
- meta.stackoverflow.com - superuser.com - tex.stackexchange.com - dba.stackexchange.com - sharepoint.stackexchange.com
Which is an... interesting set of choices. I'm not sure why you can't suggest others. I'd really like to migrate to programmers.SE. Otherwise the only option is to actually close as off-topic.
This has been asked before on HN and my response is generally "no". First, the idea of SO is that it provides a QA format so that you can reference it later. If you watch Spolsky's talk about how they built the community for SO was built, he specifically mentions "SO is not for the person answering the question or the person asking the original question, it's for the hundreds of other people who ask the same question a hundred times again". In theory this means if I want to know how to (example) "split an array in Ruby v1.9" the answer is and always will be "<insert answer>". Your answer to "here are my requirements for a new facebook startup, tell me what frameworks work best" is going to go in 100 directions and even if one answer is "the best" it doesn't mean 3 years from now that that answer will still be true. If you think about it you can easily see how much of a wasteland that would become.
EDIT: To answer your question - the only way you can make a well thought and clear decision is to implement the system yourself.
Git is the right tool for: branching and merging. And for cherry picking bug fixes from disparate branches.
The git workflow revolves around creating a branch for a feature or bug fix. Because in Git, branching and merging is cheap.
I've switched from a decade of using SVN, to Git and it is more than a shiny new tool. It is the right kind of tool for the above.
In SVN, branching and merging is expensive, and if the changes between branches were extensive enough.. the merge process would take a good weekend of manual effort. In some scenarios almost impossible to do. And in some shops I worked at, a branch with 3 months of differences would take a week to merge. SVN is not the right tool for this.
Git is like applying an N log N solution to an algorithmic problem. Great for something that in the naive case would be N² (N branches exchanging updates with each of N branches), but when the problem space is very small, whatever layer represents the log N is just overhead.
Add to this the effortless sharing and "cost-less" review provided make git a clear winner.
I think this is not exactly right. The approach is fundamentally different but not more complicated. I think that the one important concept of Git is that everyone has a complete copy repository, making the communication with a server (through SSH, HTTP or the Git protocol) just an additional feature: the very core of Git does not depend on anything.
To be honest I don't find git to be better than svn for a lot of work, having worked with both. There are fundamentally different decisions made, such as:
1 it is a lot easier to forget to add a file in svn, but it is a lot easier to accidentally include a file you don't want in git.
2 workflow in svn is a lot more streamlined because you aren't dealing with a multi-stage synchronization between your repositories (I am assuming the reason you use version control is in part to collaborate).
Now, one thing I have started to get really into has been the combination of github and svn, which gives you a lot of the benefits of svn and git together. Now, it doesn't give you every benefit of git but it gives you enough of them to make things easier all around in many cases.
Workflow with svn:
1. Edit some files.
2. svn commit -m "commit message" (ok, I add an svn up && before, but I consider that one step).
done
Workflow with git:
1. Edit some files
2. git commit
3. Review the message to see which files I actually want to add, if there is anything that needs to go into git ignore, etc.
4. Edit .gitignore as necessary
5. git add *
6. git commit -m "commit message"
7. git push
So for simple cases you have 3 times as many steps, for more complex cases you have more steps. Note that I usually push/pull from my own github repo and not a central one because that avoids a lot of other hassle (and then use pull requests for managing inter-repo changes, something github has done a nice job with).
Additionally absent this you have a significant likelihood that you end up with various files that aren't a part of your build environment (generated makefiles, backups of generated makefiles, built packages, etc) accidently pushed out to your central repo.
git commit -m "commit message" file1 file2 ...
When you use a tool inefficiently, don't blame the tool.
Also wouldn't you agree that git has a much steeper learning curve than svn? What is this due to if not the added complexity?
So, it adds one extra command to push things to an upstream git repository. But, this is the nature of being decentralized.
They should be in flat storage somewhere, with some directory or file name scheme that makes sense based on your version numbers / builds / what have you. Backed up, (ideally) with hashes that verify that they're the same file they once were.
Both systems have matured quite a bit making the comments less accurate to actually base an opinion upon.
Git seems to be the "new, shiny, cool" thing.
...
As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").
...
Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).
Perhaps that is a little harsh. I think the poster just doesn't understand DVCS's.
You can use it as a centralized repo, and it works quite well. In fact, it's how I'm doing development with LibreOffice via gerrit. However, even there I find it easier. I find my workflow is to work on a branch, make sure I have clean commits (I use rebase pretty frequently) and branch and merge often. Frankly, it's easier to work with. I find the staging model to be really excellent, and find it just easier to move up and down commits.
But looking at the quotes:
Git seems to be the "new, shiny, cool" thing.
No, no it's not.
Two modes of creating repositories
Well, sure. It's literally just a shortcut for setting up groups and then changing a global setting. Repos can go from bare to shared reasonably easily. I fail to see the point.
checkout vs. clone
Checkout checks out a branch of path to the working directory. Clone gets an entire repository and "clones" it to the current directory. There is no "versus" here, they are two completely different operations.
commit vs. push
Commit records the changes to the local repository. Push basically takes a ref (a mapping to a sha-1 value that identifies a commit in the tree) and updates a ref in a remote repository. In essence, you are pushing your changes to the remote repository. Again, the thinking of a VCS person, not someone used to DVCSes.
You have to know which commands work locally and which work with "the server"
Only if you think in terms of centralized repositories. A DVCS is distributed. It's a completely different way of thinking. I find it superior in very many ways.
Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository.
The whole point of git is that you have your version, and you either pull from or push to different repositories and and when needed. The whole idea of centralization is not core to it at all.
The author's comments here refer to the different uses of the same commands/names in git and subversion, they are not getting git commands wrong.
svn commit
git commit && git push
svn checkout
git clone
The benefits come at a cost though (I say this as someone who works with both). For many environments, a centralized VCS is all you need. Making it distributed just because that's a popular thing to do isn't necessarily always a good idea. It complicates workflows because now you have to have multiple version control systems which interact with eachother in far more complex ways. You don't want to go down that path if you don't need to.
Now, despite the costs, there are many advantages to git. These include an ability to effectively treat your local repo as a master for a client. Also DVCS's scale to a larger number of developers more than traditional VCS's and git has advantages there too.
BTW. one thing I find to be a killer feature of github is the fact that it offers you svn access to git repos, which can be really, really nice.
I'm having a hard time understanding what these extra "costs" are. I haven't used SVN in a while, but I think the only extra cost is an extra command to push your changes to a repository.
Meanwhile, the advantages of a distributed VCS are huge. Even if everyone is developing on the same LAN it seems beneficial to have a DVCS. I've been on multiple projects where the centralized VCS goes down for a day or even a week. In that scenario everyone has to stop committing changes. Sharing changes with a coworker now requires making a patch file or some other cumbersome operation.
I can't think of a situation where a centralized VCS is better for any team.
What you say might be true by at least accepted theory, and it is true that command-line git (and git has a reputation of a bad command line) is the only dcvs I have worked with but I don't see a way around the fact that since you allow more complexity in interactions between repos, this is going to have more overhead. Even you seem to acknowledge twice as many commands for version control management for the simplest cases.
I am not really anti-git even. As I say I use it for some things. But I am not at all convinced dvcs is always the right tool for the job.
Well, I didn't really say that regarding the simplest cases. There is one extra command to get something into the central repository, but basic checkouts and updates from the repository are still one command.
I've gone through the "fighting" with git stage, but it was more because I was trying to use concepts that aren't even possible with SVN rather than that git makes things more complicated.
A distributed VCS is very useful if you have a distributed team. If you don't, the distributed aspect is simply not very relevant.
1. Make your changes, branch, do whatever you want to do.
2. Commit the changes to your repo.
3. Push your changes to the remote repo.
4. When you want to get other's changes, pull those changes. Heck, do a git pull -r if you want to rebase them.
That is really not that complicated. However, you get the benefits of a local copy. So not what I'd really call totally distributed, but I can't see any downsides to this.
It's still twice as many steps. Well, probably more if you count git add before every commit.
Also a big problem for me is the necessity of a git add * before a commit, which effectively requires a lot of management of .gitignore so you don't get things like the Makefile.old getting committed. Keep in mind, all of this is process overhead, an opportunity to make mistakes, and effort (including tracking/fixing the mistakes) that could be spent programming.
There are downsides. As I say, I do a fair bit with both and to be honest I am not that enthusiastic about git over svn. It's really good in some cases. However it isn't always better. Sometimes simpler tools are better.
Personally (as a near-beginner) I have no end of trouble with the push/pull workflow. You can't pull if you have files edited, but you can't push if you're behind. 'git stash' makes this a bit less painful.
I think the thing that generated much of the initial git confusion for svn users was a lot of the git documentation at the time were devoted to using git in a very distributed, very branching, type of of manner, which while it's awesome that it's possible, is needless complexity for many dev teams. Particularly this post was passed around as the gold standard: http://nvie.com/posts/a-successful-git-branching-model/ .
A lot of svn devs were used to a pretty simple work flow. Checkout the current branch in dev, make some edits, commit/push. Rinse, repeat. On many teams no one other than the lead dev/release master would ever need to even do a merge. Now show this team the above git branching model, which suggest Bob can pull a feature branch over from Alice, make some commits and push back, but wait Sam has also needed to pull Alice's to make some commits, and merges in her latest changes from Develop which conflict with both Bob and Alices current. Now you have the lead dev or release manager wasting hours trying to figure out this merge mess with 3 broken repos and the PM demanding Sam's changes in develop are needed for a hotfix by Pat yesterday. I hope you can see the massive complexity increase in the way a lot of teams were initially told to use Git.
Once people figured out everyone could pull and push from a centralized repo (Github heavily helped this) and that branches should (for a certain type of dev team) always be pushed/pulled from the central repo instead of shared peer to peer, the workflow was much simplified. Git with a central repo is more than likely better than using svn for many teams. The easy branching and offline commits are benefits whether a team needs the "distributed" aspect or not.
It's apparent that you really understand and use a DCVS, many people do not. It's important to realize on many projects devs don't want or need to become experts on DCVS, but could still benefit from using Git over svn. For a lot of open source projects, merging and reviewing patches is a big part of the project as that's how new code gets in. For a startup team, any time spent on dealing with a VCS system is time not spent developing the product.
I think it's odd though that you use the example that someone checks out the current branch, makes some edits, then commits back in the changes. You have the same problem you highlight - if someone else makes changes, then you get the same merging issues, only this time it's on the main branch. You will still get the same project managers screaming for a hotfix, and you'll still get the same problems of merging in the changes that were checked out. After all, SVN doesn't prevent others from checking out the same files and commiting changes whilst you are making changes.
BTW, what do you mean that a DVCS is a subset of version control?
To summarize again, the post says: Git is more powerful because it's distributed - but that comes at a price in terms of a more complex UI. If you know that you'll never need DVCS, you might be better off using SVN.
Everything you are listing here is examples of how git's UI is more complex, except you don't seem to recognize it anymore because git has become so engrained in what you do. Every so often it's worth it to take a step back, to look at our workflows and to figure out why we do what we do for every step. This SO reply was IMO a good attempt at explaining exactly this in terms of the Git vs. SVN discussion.
Yes, I did indeed read the post. I wasn't jumping at "critical points", I was pointing out that he doesn't seem to have his head around a DVCS like git.
As I've pointed out a few times, the UI is not really more complex. There is literally one more step - git push - to have your changes "pushed" to a remote repo.
Benefits:
-Works offline
-Branches/Merging
-Fork another's work
-Collaboration
-Light weight and fast
-Flexible
-Tooling (github)
Drawbacks of Git:
-Hard to learn if you know a centralized SCM.
To add: there is a reason most game development shops use Perforce. Sometimes you have to deal with large binary assets. Git is just the wrong answer in that case.
- why do birds sing in the morning?
here's why from G-O-D itself: http://www.youtube.com/watch?v=4XpnKHJAok8
Awesome talk by my favorite programmer :-P
Why is Linux better than OS X?
Why is BMW better than Mercedes?
Why are Pink Lady apples better than Granny Smith apples?
Why is being an omnivore better than being a vegetarian?
The way you answer all these questions will be the same. So whether you have an answer or a process to answer these questions, you'll have a pretty good idea about git vs svn.