I switched to git from mercurial about two years ago. See here why I switched and here my experience after 4 months. Back then I was unsure, whether git will win, but I thought it has a bigger momentum. Well, I think that now it's quite clear that git has already won. Pretty much everybody that I collaborate with is using git now.
I use github everyday, and now thanks to github pull requests, I think it's the best collaboration platform out there (compared to Google Code, Sourceforge, Bitbucket or Launchpad).
I think it's partly because the github guys have a clear vision of what has to be done in order to make collaboration more easier and they do it, but more importantly that git branches is the way to go, as well as other git features, that are "right" from the beginning (branches, interactive rebase, and so on), while other VCS like bzr and mercurial simply either don't have them, or are getting them, but it's hard to get used to it (for example mercurial uses the "mercurial queues", and I think that is the totally wrong approach to things).
Anyway, this is just my own personal opinion. I'll be happy to discuss it in the comments, if you disagree.
22 comments:
No arguing from me. I was actually an avid bzr user, but with no really simple web interface and (sadly) the sluggishness of it all, forced me to try git and now I really like it. Even though I sometimes miss the easy-to-use command set of bzr. (The easygit project is a great idea though...)
I too use GitHub (as a backup to my private server) and find it extremely user friendly!
See you there!
/Joachim
GitHub is non-free:
http://mako.cc/writing/hill-free_tools.html
I suggest gitorious.org, I will always use it over github because it's free software.
I like git's speed. I love gitg as a GUI (even though colored text-mode git diff is awesome too). And I think github is the clear leader right now not only because of their awesome feature set, vision and design, but also because there is a lot of people there, so you find a lot of projects and there are a lot of users publishing their own forks in there. It has momentum and critical mass.
We had the exact opposite experience at work. We inherited a Git repository from a previous development team. We spent 2 months trying Git and using it, and hated it: obscure commands, unintelligible errors, and incompetently written documentation.
So we converted to Mercurial just over a month ago. It's so much easier. It's just as powerful, but we can actually remember and use all the commands, without worrying that we're going to inadvertently destroy some portion of our codebase. We're much happier.
How do github's pull requests compare with bitbucket's pull requests, in your opinion?
Mercurial has interactive rebasing independent of mq; both transplant and rebase operate interactively.
While I would like to agree or disagree based on an experienced comparison, I found git's experience on Windows to be a showstopper, especially after I diligently tried and failed to set up a web server repository. C'est la vie.
Otherwise, I've found Mercurial's support for the features you discuss above to be excellent, including rebase. Can't comment on github versus competitors.
Fortunately, cross-compatibility between git and hg seems to be excellent, so we're not all forced to choose sides.
Thanks for all the comments.
Fernando pretty much summarized my whole point --- that git (and github) has the critical mass and momentum.
Yes, I think that there is one-to-one correspondence (of features) between git and mercurial, as the hg-git shows.
The problem with mercurial queues (MQ) is that those are not equivalent to git branches (mercurial benchmarks are). In git, there is just one way of doing things (git branches), it's the standard thing, and it's also the best way to do things (in my experience). In mercurial, there are so many ways to do the same, and many people advocate to use MQ, but such a workflow is more tedious than git branches.
So even though theoretically one can do everything in mercurial that one can do in git, in practice, people don't (until hg benchmarks become the standard way to do branches in mercurial).
As to easiness of use -- well, I have managed to teach git to everyone around me, yes, sometimes some people complain that it is too complex, but if all you do "git commit", "git push", it really is not. If you go into git branches, it might be a bit confusing at first --- but it is equally confusing in hg, if you want to do the same thing (hg bookmarks). Once you understand how to work with "branches", I think that git is actually easier than mercurial.
As to pull requests in bitbuckets, I never tried it, so I can't claim anything -- but I couldn't find any documentation -- is it based on MQ? If so, then my above comments apply -- MQ are not as good as git branches.
I have used Mercurial for about a year and Git for about 2 months. I prefer Mercurial:
- much cleaner command set, Git commands are obscure (eg. the same command "checkout" is used for switching branches and reverting files)
- can do harm if you are not sure what you are doing (removing commit in Mercurial leaves "undo data", nothing like this in Git)
- merging conflicts in Mercurial is done in nice GUI for default (kdiff3 etc.), in Git it leaves files with markers.
- ability to write hooks in Python, much better than raw shell/Perl scripts in Git
However I see some advantages of Git:
- good default in-repository branching model. Mercurial in-repository default branches model (tagging every commit with branch) is worse. There is "bookmarks" extensions which copies Git's branches but it's extensions only.
(and I don't understand why you mention patch queues as a branch model for Hg?? It's something different) However I'm happy with branch-as-clones model and don't need in-repo branches.
- GitHub feels better than BitBucket
To sum up - Mercurial is cleaner and much more user-friendly, Git has a better in-repo branch model.
Ondrej> As to easiness of use -- well, I
Ondrej> have managed to teach git to
Onfrej> everyone around me
Well, your own supervisor told me that even after a year he was still struggling using git :) (granted, he had a beer in his hands when he told me that.
Bitbucket supports MQ, but I guess I don't understand the problem using standard named branches in HG? Why are the bookmark extension and the MQ extension superior?
The whole thing just seems so primitive. I mean source control really a contest like a sporting event, where someone *must* emerge as the victor? Another world is possible - e pluribus unum...
@Jacek:
- If you've made a commit in git, you will never lose that data. Check out git reflog (http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#recovering-lost-changes or http://gitfu.wordpress.com/2008/04/06/git-reflog-no-commits-left-behind/)
- Merge conflicts in a visual tool is handled by git-mergetool (http://gitfu.wordpress.com/2008/06/09/git-mergetool-when-just-doesnt-cut-it/ or http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#resolving-a-merge)
I've never needed to write plugins, so I can't really comment on that point.
Just because you don't know how to do something with git, doesn't mean you can't actually do it. The reflog is one of the most powerful features of git and a lot of people just don't even know it's there.
Matt,
I think that hg named branches are a bit different than git branches, as explained for example here:
http://www.lostechies.com/blogs/jimmy_bogard/archive/2010/08/25/why-hg-branches-are-broken-or-at-least-less-useful.aspx
and I think that the git way is better, because it seems to work for everyone --- in mercurial, people have created MQ, bookmarks and named branches. Also, since bitbucket decided to use MQ, it means that not everyone agrees that named branches is the way to go.
So I think that the git workflow is still a bit difficult in mercurial (see for example the link above). You can of course argue that the "git workflow" is bad and one should use "mercurial workflow" and that is perfectly fine --- time will tell which one people like more.
Gaël, yes it was hard for my supervisor, but you should ask him now, what he thinks about git and github. :) Also, quite frankly, it would be hard in mercurial too, learning MQ and pushing to bitbucket and so on.
Git is simple, but its UI is awful. Many people don't make the difference, I think that's the core issue.
I am using hg at work, so I am using it on a daily basis, and I really don't like it much - I find it actually more complex than git because you need to know many more concepts to use it effectively. I find queues confusing, the named branch/bookmark/clone difference annoying as well, and the lack of index a significant drawback. I really miss a lot of git features in hg.
Comparing branches and reviewing other people's code in particular is particularly annoying with hg, maybe I have not found the "right" way of doing it.
Hg advantages are not simplicity IMHO, but in its cross platform nature. Although git is usable on windows, there is no question that hg performances/behavior is much more consistent across platforms.
I was fortunate enough to learn git from the outset. Actually, this is thanks to you, because you were using git in SymPy. So I don't have any experience with any other version control systems, and only know what I have read.
However, even without other systems to compare, I can say that git is very amazing on its own. I have recently gotten into the habit of typing git init in the directories where I do my homework assignments. Recently, I did a group project for a class where the other group members also knew git, so we setup a server. It made things 10x easier being able to edit the same document as someone else without having to worry about losing changes in the transfer, or having to do merging, because git takes care of all of that automatically.
Also, for the programming assignments, git has made it very easy to experiment with something without having to worry about breaking anything.
For SymPy, it is of course the most useful. This summer, I had to do a very large merge with Mateusz's polys11 branch into my integration3. He had moved code into different files, some of which I had edited in my branch. The merge took a while to complete, but I don't imagine I would have ever been able to do it without the bookkeeping that git does for merges.
As for GitHub, I really like it. I think the pull requests still need some more features added, but even as it is now, it is really good. I have noticed a spike in people submitting patches to SymPy ever since we started using it, including many people completely new to submitting patches to SymPy.
As for it being free or not, much of the code is open source (see GitHub user github). If you are talking about GPL, who cares? Thanks to the distributed nature of git, it's not like they can ever steal, hijack, lose, or hold your code ransom. But really, who cares? SymPy isn't GPL, so I suppose you shouldn't be using it either, notwithstanding whether or not it is actually good software or not.
I don't understand, why do you insist to use mercurial's MQ feature instead of regular branches. First of all, MQ is a tool for completly different purpose. It is supposed to support off-the-repository contributions, not to do day-to-day branched development. This is done by normal use of hg branch command. BTW, no need to mark each commit as a member of a branch. Once you set your working dir as a branch X, it stays in it, unless you update it to different branch. Dead simple. Jacek's comment "Mercurial in-repository default branches model (tagging every commit with branch) is worse." is a complete nonsense or he's talking about some different vcs.
As many of comments said before, Mercurial has much cleaner syntax (compare hg update/git checkout) and saner defaults. Besides it doesn't allow to screw with history, like git, so nobody will chop his coleague's arm with it.
One thing that Mercurial wins for me is that you can push to any repository. You don't need to mark particular repo as bare one just to make a push to it. No second-class citizens here.
Cezio, read here why the hg branches can't easily be used like git branches:
http://blog.experimentalworks.net/2008/11/mercurial-bookmarks/
due to that, you need MQ and bookmarks.
Also please see jchu's comments about reflog (e.g. I have never lost anything in git history...).
Git actually has two equivalents for "Mercurial Queues" --- stgit (Stacked Git), and "guilt" (which stores patches in a quilt-compatible format).
For some applications, "guilt" is the right tool to use if you need to refine a patchset and get the best of both worlds (quilt and git). Once the patches are perfected, I can then freeze them into a permanent form, and export them as a git branch which then gets merged into mainstream.
@cezio
You can push to any git repo too... They're all first class...
It will complain if you're trying to push to the currently checked out branch (HEAD, in git parlance) because the user working in that working copy will see the opposite of those changes when they git diff.
If you do run into this specific issue, all you have to do is set the "receive.denyCurrentBranch" option in the target repo to "warn", false, or "ignore" and it will let you do it anyway.
I'm curious how hg handles this issue. Does it just update your working copy as well? What if the owner of that working copy wanted the original file? Aren't you stepping on their work?
Ondrej: Firts of all, this post is 2.5 year old and refers ancient feature set of mercurial. Bookmarks is already developed (please, note notes on the bottom): http://mercurial.selenic.com/wiki/BookmarksExtension
I still don't understand why do you want to use MQ or bookmarks as an equivalent of normal branching in mercurial. Normally, you don't use spoon as a knife.
Internal mechanics behind it is of course different from the one in git, but day-to-day development functionality is really near the same. Use cases mentioned in cited blog posts are mostly cases when you want to fiddle with your repo in a dirty way.
Post a Comment