Distributed version control systems (DVCSs) offer a number of advantages over centralized VCSs, and for Subversion users looking to explore this model, Git is a great place to start. Using Subversion as a baseline, this articles shows how to install Git, set up a remote repository, and begin using basic Git commands.
Post a Comment
Member since:
2006-01-01
Member since:2005-07-03
Still "shocking", on the other hand, the "DVCS offers an advantage" sounds like a fact, when in truth, for some others that's not the case.
Member since:2005-07-07
Member since:2007-09-22
I've been thinking, maybe Mercurial (hg) is a good idea on Windows, Mozilla for example uses it.
edit: Then again, maybe git isn't all that bad:
http://nathanj.github.com/gitguide/tour.html
Edited 2009-08-05 23:46 UTC
Member since:
2009-07-01
This one just came out on the same subject: http://chaosradio.ccc.de/cre130.html
Edited 2009-08-05 16:27 UTC
Member since:
2007-04-29
Git is far too much GPL to be used by human beings.
For fun, compare the video of Linus talking about Git and the Mercurial guy talking about mercurial. Now ask yourself, who do you prefer?
Git : http://www.youtube.com/?v=4XpnKHJAok8
Mercurial : http://www.youtube.com/?v=JExtkqzEoHY
Member since:2007-09-22
Member since:2005-07-24
Linus, of course. :-)
IIRC, when Linus was shopping for a revision control system, he liked Mercurial's architecture. Which is saying quite a lot, because he disliked most everything else. Mercurial's fatal flaw was it's speed, or lack thereof.
Git is blazingly fast. But Andrew Morton himself has joked that you have to be as smart as Linus to really *understand* git.
That said, git really seems to have taken off. I do a lot of work with Django, which is a (fantastic) Python web framework. You might think that Pythonistas would gravitate toward Mercurial. But Git, Git, Git is the thing. Even though most of what it's used for could be about as well served by Subversion, or even CVS.
I must say, though, that your choice of the subject "gnuism" for this thread is way off the mark. Linus and the FSF are hardly chummy. Linus likes the "tit for tat" aspect of GPLv2. He doesn't particularly like the legal "second system syndrome" that is GPLv3.
Edit: The choice of phrase "second system syndrome" is mine, not Linus's. But I suspect he would agree with it.
Edited 2009-08-06 00:32 UTC
Member since:
2006-01-18
Linus was not really having a look at mercurial upfront it was DARCS.
But back to GIT and Linus talk about it. I use git on a day to day base, but I would shun to introduce it into a project. The learing curve is way to steep and will be for the forseeable future, and it has so many inconsistencies and pitfalls you will run into over time in its command set. While the start is easy and clear, git init, git add -a git commit git branch, git starts to rear its ugly head at the time you want to share a branch:
example: git share <branchname> as it should be is in reality:
git push origin origin:refs/heads/${branch_name}
git fetch origin
git checkout --track -b ${branch_name} origin/${branch_name}
git pull
or even a simpler case, git checkout should do a checkout, but
git checkout HEAD simply without any hint produces a floating head and then sets your current head onto it, no user feedback nada
git checkout HEAD . does what you want to do instead
So if anything fails you suddenly start to commit into a floating head and you still think you are in your normal head.
even worse:
git revert does not the same as normal reverts in absolutely any other revision control
git revert HEAD simply drops your head and checks out the revision HEAD-1
git revert HEAD must be either used as git stash, git checkout . (the safe way)
or git reset --hard HEAD (the hard way where you can loose all uncommitted changes into oblivion)
All of this could be cleaned up, and projects like easygit already cut it to 90% (except that eg still does not have a good sane remote branch handling)
but I would not dare to recommend git until the porcellaine really is usable by day to day users.
The problem is mercurial already has all this but it lacks lightweight branching you have to add via external plugins.
And the other one is the lack of a well working alternative to git-svn. As soon as HG gets its act together regarding the lightweight branches and svn connectivity there is a hard justification to use git at all.
Edited 2009-08-06 10:20 UTC
Member since:2006-10-24
You're correct in that there are some inconsistencies and UI warts but they're hardly difficult to grok. There is a simple elegance to Git which becomes apparent once you understand it a little better.
example: git share as it should be is in reality:
git push origin origin:refs/heads/${branch_name}
git fetch origin
git checkout --track -b ${branch_name} origin/${branch_name}
git pull
This is just plain silly. There is no reason to jump through all these hoops:
git push origin ${branch_name}
will publish your local branch to the "origin" remote repository. All your other commands are recreating a local branch which by definition you already possess.
or even a simpler case, git checkout should do a checkout, but
git checkout HEAD simply without any hint produces a floating head and then sets your current head onto it, no user feedback nada
Git is designed for the power user as opposed to the newbie, but there is nothing so wrong with what you describe above. The newbie should simply checkout the branch _name_ they're interested in, not HEAD.
So if anything fails you suddenly start to commit into a floating head and you still think you are in your normal head.
This is hardly the end of the world, it's easy to fix up such a newbie mistake without losing anything.
even worse:
git revert does not the same as normal reverts in absolutely any other revision control
git revert HEAD simply drops your head and checks out the revision HEAD-1
You're just plain incorrect here. "git revert HEAD" will make a new commit that undoes whatever was done in your HEAD commit.
However, if you have not yet published the incorrect commit you made in HEAD (which is often the case), you can simply amend the commit in place (git commit --amend), or use several other powerful tools to fix it (git rebase -i, etc).
All of this could be cleaned up, and projects like easygit already cut it to 90% (except that eg still does not have a good sane remote branch handling) but I would not dare to recommend git until the porcellaine really is usable by day to day users.
You're really making mountains out of molehills. Git is pretty straight forward to learn and a pleasure to use with many great features. Once you've spent some time using Git, returning to SVN is a real hardship.
Edited 2009-08-07 18:30 UTC
