3 reasons to switch to git(markmcb.com)
markmcb.com
3 reasons to switch to git
http://markmcb.com/2008/10/18/3-reasons-to-switch-to-git-from-subversion/
37 comments
Each version control model has it's own merits and drawbacks, and there will always be situations where one is good and another isn't. For example, while many OSS projects have switched to distributed vc's such as git and mercurial, two of the largest oss projects still remain loyal to Subversion, FreeBSD and KDE. If you search their mailing list archives, you will see that after long thought, both projects decided that the Subversion model reflects better their development style. So, no, git is not simply "better" than subversion, it just reflects a different development methodology.
The nice part is that with git, one can interact with svn projects seamlessly via git-svn -- so endless local commits may be repacked to one single remote commit or push.
But svn lacks suh flexibility to interact with others. Hence git > svn, as in svn is a tiny subset of git.
But svn lacks suh flexibility to interact with others. Hence git > svn, as in svn is a tiny subset of git.
It's not so simple. For example, if I remember correctly,git lacks a way to checkout and work on a small subset of a development tree, as it tracks whole trees at a time. This feature is something that svn and cvs offered long ago. To do that with git you have to break the tree into small sub-trees, as the X.org guys have done. This may be considered as a drawback for some people.
For more information on why git was not chosen instead of svn for FreeBSD you can look at http://wiki.freebsd.org/VCSWhy
Again, each vc has it's uses, and nothing is merely a 'subset' of another.
For more information on why git was not chosen instead of svn for FreeBSD you can look at http://wiki.freebsd.org/VCSWhy
Again, each vc has it's uses, and nothing is merely a 'subset' of another.
I'll add a fourth, which is the "killer feature" for me and my current workflow:
Git allows working from more than one system at once without requiring a constant server connection. When I'm on the go and want to make changes to my code from my laptop, I can make commits, I've got access to the full history, etc. All that's required is a pull from my desktop before I leave my office, and I've got a shell script that pulls the repositories for all my projects at once.
With something like SVN, this kind of thing was a major pain, as I'd either have to work just with my local copy on the laptop (leading to poorly tracked mega-commits), or copy the whole file system structure of the repository to the laptop, which quickly gets you into desynchronised territory. Add another developer and you're instantly dead with that kind of system.
Git allows working from more than one system at once without requiring a constant server connection. When I'm on the go and want to make changes to my code from my laptop, I can make commits, I've got access to the full history, etc. All that's required is a pull from my desktop before I leave my office, and I've got a shell script that pulls the repositories for all my projects at once.
With something like SVN, this kind of thing was a major pain, as I'd either have to work just with my local copy on the laptop (leading to poorly tracked mega-commits), or copy the whole file system structure of the repository to the laptop, which quickly gets you into desynchronised territory. Add another developer and you're instantly dead with that kind of system.
Mercurial provides the same "killer feature", which I think nullifies any "killer feature" status for git (implies exclusivity, I believe).
Fine. Call it the killer feature of distributed version control systems. Works for me, in any case.
Why do you prefer Git to Mercurial? I've only used Mercurial.
I'm not an expert in git (still learning) and I've hardly used Mercurial at all, so right now there's no particular reason. There are probably better people to ask that question. :) I'll try hg in a project sooner or later, but learning to get to grips with 2 version control systems at once while trying to do something productive seemed a bit much. There wasn't really anything on the feature lists that tipped the scales; the Linus Torvalds association and the resulting curiosity probably did.
I can't believe I fell for a celebrity endorsement. ;)
I can't believe I fell for a celebrity endorsement. ;)
I prefer Mercurial for mostly cosmetic reasons (I believe that Git and Mercurial are very close, feature-wise). I prefer having one command "hg" ("hd add", "hg serve", etc.) to the dozens of commands for git. I think it has more to do with the way that I think than anything else: Mercurial commands are easier to remember for me.
Um, "git add", "git push", etc. work fine. I think the hyphenated versions are deprecated anyway.
Why git? It's popular, which means it's easy to find people to ask questions when you need to.
Really, I'd be fine with any fast distributed VCS, which means nearly all of them these days. (sorry Darcs). The ease of setup ("If you have SSH you have a git server") feature is also very nice, but I don't think it's exclusive to git.
Really, I'd be fine with any fast distributed VCS, which means nearly all of them these days. (sorry Darcs). The ease of setup ("If you have SSH you have a git server") feature is also very nice, but I don't think it's exclusive to git.
Same here... I work on the train during my morning/evening commute to the office. Being able to commit and branch offline is a major win.
I sometimes feel like the technology world is similar to the fashion industry - this year CVS is, then it's suddenly SVN, and when I make the switch, everyone is using GIT, and I'm sooo last year with my SVN.
I'll wait out the GIT wave. If it's more dominant than SVN in 2011, that's when I'll switch.
I'll wait out the GIT wave. If it's more dominant than SVN in 2011, that's when I'll switch.
As others have mentioned already in this thread, the git-svn bridge works very well. You can adopt git and get a bunch of its features (local repository mirrors and multiple local branches) while still working atop your SVN repository. You give up some things (you can't really do cross-repository merges with git-svn -- when you want to communicate with your peers you have to do it via the SVN repo) but it is still great. It's not worth waiting another five years for the extra features. ;)
I've found that the CVS-to-git workflow is a bit more annoying. You can import CVS repos into git, but you can't really push anything back without using patches.
I've found that the CVS-to-git workflow is a bit more annoying. You can import CVS repos into git, but you can't really push anything back without using patches.
I just started playing with git, and yeah, it's definitely better in a few ways, but it didn't jump up and start writing code for me, so your approach is a sensible one. My guess is that companies are not made or broken on the differences between vc systems - as long as you have a decent one, you're ok.
As a recent switcher to git, I like your fashion analogy. It's like I'm wearing what others call the latest fashion, but it sure looks the same to me. All the colors are different, but I end up wearing it the exact same way.
When you delete the master branch, you are enlightened.
Ha! That's awesome!
Haha, nice.
Explain.
The concept of a primary working tree is a relic of non-distributed VCS? I could see working with several branches or versions of a project but not having any single canonical version. I've never done it, but I could see working that way.
Exactly.
On our project we deleted the master branch in favor of having two branches we work off of: production and development.
The production branch reflects what is in production while development contains new completed features that each developer builds in all of their own branches.
On our project we deleted the master branch in favor of having two branches we work off of: production and development.
The production branch reflects what is in production while development contains new completed features that each developer builds in all of their own branches.
"You’d like to work on each of your 4 features A, B, C, and D independently and somewhat in parallel, though B looks like a quick win."
Does anyone here seriously work like that?
Seems like git has some advantages if you branch a lot, but I don't think branching too much is particularly healthy. I can see why it's good for open source if you have a ton of contributers, but what's the win for a small team who hardly ever branch?
Does anyone here seriously work like that?
Seems like git has some advantages if you branch a lot, but I don't think branching too much is particularly healthy. I can see why it's good for open source if you have a ton of contributers, but what's the win for a small team who hardly ever branch?
I don't use git, I use bazaar - but yes, I often work like that. Why? Sometimes my headspace fits one class of problem better than another, other times I might want to push a largish patch early to another team member, sometimes you want to break a lot of stuff as is often the case with exploratory programming. Short lived branches can be very handy.
I do this all the time on the GitHub repo itself. I'll have an idea for a small tangential feature (like per-repo pageview stats) that I want to spend an hour hacking on to see if it goes anywhere. By branching off master, I can experiment to my heart's content and then just shelve the feature easily if I don't finish it. Then later on, getting it back is just a single command away. Git really is a hacker's best friend. It facilitates exploration and experimentation of code. Fits perfectly with a startup mentality.
Does anyone here seriously work like that?
Sure, why not? I create a branch for nearly every series of edits (aside from tyop-fixing bugfixes) that I do, usually to fix a bigger bug or to create a new feature. If it works out, great: I merge it into the master. If it turns out to be a dead end, or is taking too long, I can delete the branch, or just put it aside with the intention of rebasing it later.
...but I don't think branching too much is particularly healthy.
Again, why not? Ignoring for the moment problems which are social at their root and not a dvcs' fault, most likely either you're creating lots of dead ends in those branches, which isn't such a bad thing because it also means that you're also trying out lots of ideas and exploring the problem space; or you're merging those branches, so you're doing good work and getting it integrated into the project.
Sure, why not? I create a branch for nearly every series of edits (aside from tyop-fixing bugfixes) that I do, usually to fix a bigger bug or to create a new feature. If it works out, great: I merge it into the master. If it turns out to be a dead end, or is taking too long, I can delete the branch, or just put it aside with the intention of rebasing it later.
...but I don't think branching too much is particularly healthy.
Again, why not? Ignoring for the moment problems which are social at their root and not a dvcs' fault, most likely either you're creating lots of dead ends in those branches, which isn't such a bad thing because it also means that you're also trying out lots of ideas and exploring the problem space; or you're merging those branches, so you're doing good work and getting it integrated into the project.
I think it's considered unhealthy because it's another layer of complexity you have to deal with, and a many-branched environment without any system-enforced meta-structure can result in huge amounts of confusion when things don't go right. You have to train your team and trust everyone to avoid all human error. Example: "whoops, I just merged a bad branch into the master one, but I just left work for the day and I don't find this out until tomorrow morning, let's hope no one checked it out in the interim or we're boned!"
With a centralized VCS (or more specifically a single- or few-branched repo), you just tell people to checkout code, commit their changes, and you're done. There are less places to screw up because you don't have a bunch of branches you have to manage. You are less flexible, but this lack of flexibility only becomes a huge burden in a truly distributed (i.e. open source) environment.
It's sort of like arguing static vs. dynamic typing. There are many cases where dynamic typing resulted in very painful errors because some variable along the line didn't follow the "gentleman's agreement" that it should be a list and not a string. Though dynamic typing is more flexible and powerful, sometimes you just succumb to human error because the computer trusts you.
With a centralized VCS (or more specifically a single- or few-branched repo), you just tell people to checkout code, commit their changes, and you're done. There are less places to screw up because you don't have a bunch of branches you have to manage. You are less flexible, but this lack of flexibility only becomes a huge burden in a truly distributed (i.e. open source) environment.
It's sort of like arguing static vs. dynamic typing. There are many cases where dynamic typing resulted in very painful errors because some variable along the line didn't follow the "gentleman's agreement" that it should be a list and not a string. Though dynamic typing is more flexible and powerful, sometimes you just succumb to human error because the computer trusts you.
SVN doesn't do anything to stop people from committing a bunch of boneheaded changes to the repository either. Maybe its a harder to do by accident, but in practice I don't see that as much of a problem. Also, if if someone does commit a bad branch to the repository in git it can easily be rolled back.
Yes. At work we've got several small teams (sometimes just one person), and each work on their own branches (basically, there's release branches and branches with shared content too). With a single team or just a handful of people this may seem crazy but honestly not branching often just doesn't scale well beyond a certain number of engineers. So you're right, for a small team it may not be worth it. Yeah it's easy to lean across the table and tell your cofounder they broke the build but I'd still say it's a good habit, since you can always launch versioned code and not include any unfinished features (and potential security holes).
At work here we have separate branches for each major feature release under parallel development. There's another branch for any high-priority fixes going into production outside of the normal release schedule. There's a lot of merging going on cross-branch and git would make this whole structure much easier to follow. We're using CVS and honestly it's a huge pain for our workflow.
An appeal to authority argument: newly released Android code is kept in git repository. Google built a new wrapper around git called "repo".
seems like git isn't designed to handle long-running branches, or branches with more than one committer. i'm still pretty novice at git, and was hoping this article could clear that up, but mailing patches around seems .. inefficient.
anyone want to correct me? i like git in most respects, and am now using it on a few projects.
anyone want to correct me? i like git in most respects, and am now using it on a few projects.
Hm? Why would you think that?
Did you realize that your master/ branch is just one such long-running branch, and one that's not special in any way other than being the default for some commands...
As far as multiple committers on one branch -- well, you can do it, but with 'git rebase' and friends, it's just easier to do your own work on a short lived branch off your primary branch, and just merge in stuff as you get it done.
It's not that git makes it difficult to do it compared to other version control systems; it's just that it's a nicer workflow if you use short-lived topic branches to do development because you don't to worry about what other people are doing until you decide you want to take a look at it and merge it in. The short-lived private branch + lots of merges workflow is just easier because it prevents interruptions in your workflow.
As far as emailing patches, it's a matter of taste. It's certainly easier to make sure all changes get reviewed if patches are mailed around, because people tend to read their mails. Personally, I just use a post-update hook to mail out a list of changes for each commit, and review them later, since it's always relatively easy to back out or fix a patch -- after all, it is a version control system.
Did you realize that your master/ branch is just one such long-running branch, and one that's not special in any way other than being the default for some commands...
As far as multiple committers on one branch -- well, you can do it, but with 'git rebase' and friends, it's just easier to do your own work on a short lived branch off your primary branch, and just merge in stuff as you get it done.
It's not that git makes it difficult to do it compared to other version control systems; it's just that it's a nicer workflow if you use short-lived topic branches to do development because you don't to worry about what other people are doing until you decide you want to take a look at it and merge it in. The short-lived private branch + lots of merges workflow is just easier because it prevents interruptions in your workflow.
As far as emailing patches, it's a matter of taste. It's certainly easier to make sure all changes get reviewed if patches are mailed around, because people tend to read their mails. Personally, I just use a post-update hook to mail out a list of changes for each commit, and review them later, since it's always relatively easy to back out or fix a patch -- after all, it is a version control system.
with git you don't checkout, you clone. then you branch that clone locally. if you want other people to work on that branch, you can git push that branch to the origin server repository, and other people can then git pull it, and of course any member can then simply git push it whenever they commit and it will be widely available.
Only one reason needed:
git > svn
git > svn