Git or Mercurial

Monkey Archive Forums/Monkey Discussion/Git or Mercurial

Kalakian(Posted 2012) [#1]
I've been using Subversion for my projects for years now, and have finally decided to take a proper look at Distributed Version Control Systems ... but which one?

Without flaming or being fanboyish, can anyone give me a good reason why to choose Git over Mercurial, or vice versa?

Samah(Posted 2012) [#2]
@Kalakian: I've just got Taiphoz using source control, so stop hassling him to use a different one while he's getting used to SVN :P

Nooooo stop him now! Getting used to Subversion is a bad thing! XD

To me, Git vs. Mercurial is six/half dozen. I chose Mercurial because:
a) A guy at work recommended it.
b) Another guy at work gave a one hour session on it.
c) I find TortoiseHg to be nicer than TortoiseGit, and I haven't seen any other decent GUI tools for Git. Knowing the command line parameters for Hg/Git is nice, but I'd rather do two clicks and get back to coding than to start up a command prompt and type stuff.
d) At this point in time, I don't see any reason to move to Git when it seems very similar.

Raz(Posted 2012) [#3]
I can't really give a detailed response but I've gone with Git and did so once a decent Windows GUI was introduced (which was quite recently by Github themselves).

Git does what I need, and the GUI is very easy to use.

Kalakian(Posted 2012) [#4]
Ok, you've both given reasons that can be summarised as "just because", which doesn't help me much :P

I should point out that I'll be using the Tortoise client whichever one I do go for, because it's just superb ... TortoiseSVN, TortoiseGit and TortoiseHg already installed.

Paul - Taiphoz(Posted 2012) [#5]
Yeah I am enjoying the tortoise client as well, but that does not really go for much because I don't really have any experience with anything else.

I actually really hope that no one answers you with a really good reply derek cos Iv just spent the night porting and adding "!ALL!" my monkey max and b3d , php ........ etc projects to be SVN managed.

Oh and I installed that Visual SVN server, which is so simple to use it's kinda mind blowing.

<whisper>so if you have a really good reply.... GO HOME!</whisper>


ziggy(Posted 2012) [#6]
Both Github and Mercurial are great and MUCH BETTER than SVN in absolutely everything.

I would go for Mercurial becouse:
-It's easier to find complete how-to documentation and guides for beginers. In fact everthing can be seen here:

-From my experience, it seems to be a bit faster than Github

-Github documentation is spread and not always up to date

Anyway, you would be choosing between two great technologies and for a project of this size where branching should be allowed, encouraged and handled properly, staying away from SVN is a godsend.

Samah(Posted 2012) [#7]
I'm happy to go with either. I only have preference to Hg because I have it installed. ;)

Paul - Taiphoz(Posted 2012) [#8]
ziggy that HG init link instantly put me off, years ago I did nothing but work in cli's but now I really cant stand them and feel that if I have to drop down into shell or command that the application I need to use has failed in some way.

Namely having a good working GUI to use.

It's 2012, nothing should be done in a cli, and anything that actually needs to be done in a cli should be done behind the scenes away from the user.

My own personally opinion, but unless Mercurial or Git has a nice working front end I wont even give them another thought.

ziggy(Posted 2012) [#9]
@Taiphoz: There's nothing forcing you to use the command line, but it's recommended that you understand the tools you use and using a Gui frontend that prevents you from learning what you're doing is inmediatly fast but counter-productive in the long run. It was just an advice. Take it or leave it. Tortoise for Mercurial has a reputation of working well, but I would never seriously recommend staying away from the console when working with any version control system. Specialy on 2012.

My own personally opinion, but unless Mercurial or Git has a nice working front end I wont even give them another thought.
But what are the benefits of sticking to an old-dated unproductive and branch unfriendly system like SVN. I thought it was 2012!! :D

Anyway, it's an advice, you're free to ignore it if you prefer to stick with SVN. I personaly won't be prociding code for the project becouse of current workload BUT I would love to participate in any other iteration of the project. It looks like a very nice idea.

I see it more or less like SVN is a Gosub, while Mercurial and Github are propper function calls.

Tibit(Posted 2012) [#10]
I have perfered SVN because of their Windows integration - called tortoise.

Well guess what. GIT and Mercurial both has Tortoise clients these days.

So these days I have all three installed (because as a programmer you will inevitably end up wanting to look at code from all three systems)

SVN is what I am used to. I never got the benefit of HG or Merc because they trade the most valuable thing of ALL friendlyness for performance & features.

So on a feature stand-point, they win. Speed, they win. Optimized Disk Useage, they win.

These days though (if you use Tortoise) the user friendlyness is the same basically. And SVN do create problems from time to time, especially on bigger projects. It can be a mess.

However before commiting code on HG it is essential to not use the SVN way of doing things - because then they are just worse. But if you work the way they intend I only see benefits.

Bottom line - The downside is that almost none can easily explain HOW TO use Merc/HG. It is as simple as SVN with the Tortoise interface tough.

I would, but don't feel like I have time now to write a proper guide - maybe we can do this in this Thread. Because at the end of the day if you combine bitbucket (FREE repository in the cloud online, unlimited commercial projects, but costs when you are more than 5 users) or googleCode (for OpenSource project only) WITH HG/Merc then it is so far the most awesome CodeHandling I know.


Paul - Taiphoz(Posted 2012) [#11]
I just realized that Derek (Kalakian) said he had tortoisHG and Git, so my previous front end comment is kinda void now, and I have now downloaded both those clients.

I am reluctant to install them however, I don't fancy having a huge context menu with three different source control systems in it.

@Ziggy, yeah of course it's old but its new to me, and I'm still learning it and have as of yet not found any problems with it, so thus far I am happy with TortoiseSVN and VisualSVN to manage my code.


For argument's sake , lets assume I wanted to try something new, like Git, or Merc, would it be possible for me to convert my SVN repositories over to both of those systems or will I need to make new repositories for each of them.

Also I am using VisualSVN windows svn server for my own work, does Merc and Git have an equivalent ?

Kalakian(Posted 2012) [#12]
Thanks for the answers everyone. Looks like I'll be flipping a coin between the two of them as all answers just seem to be personal preference or "yes, use one of these" :)

I do like SVN's simplicity and still think it is really useful for small team or individual projects where de-centralising is just an unnecessary complication.

I agree with Taiphoz that CLI shouldn't be used much nowadays except for at server side where it is essential. Whichever I go for, I'll be using the Tortoise client and only dropping down to CLI if I'm doing something a bit obscure and not in my general workflow.

From what I've seen so far, Mercurial seems to be the more straight-forward, but the branching isn't as good as Git. What do you Merc users think of the branching?

Kalakian(Posted 2012) [#13]
Here's an example of how I'd like to use branching, to give you a better idea:

Project reaches V1, so create a branch for V1, keeping the trunk for continuing on towards the next version.

While working on V2, I get a bug report for V1, and after testing, I find it's in V2 as well. I fix it either in the trunk or the V1 branch and push it to the other version, without pushing new features from the trunk into V1.


Please bare in mind that I haven't really used branching before, so if that's really not how you would use it, fair enough, but how would you use it then?

Paul - Taiphoz(Posted 2012) [#14]
the way I was thinking that branching would work is that if I am in the middle of code, and have options as to what to do next, I might two or three beaches to code and est those changes, if I then decide that branch four's code works the best I have a way to push that into the trunk.

or is that not how it works ?

Kalakian(Posted 2012) [#15]
@Taiphoz AFAIK experimental branches like you describe are quite common, so I would like to be able to do this as well.

Paul - Taiphoz(Posted 2012) [#16]
SVN does not do this tho right ? which I suspect is what people have a gripe about. or am I wrong ?

Kalakian(Posted 2012) [#17]
SVN does do branches. Creating the branches is simple, but there are horror stories of when it comes to merging the changes. If I could do both the above examples of branching with SVN without too much hassle, I probably wouldn't even bother looking at Git or Mercurial

Xaron(Posted 2012) [#18]
Definitely Mercurial!

Paul - Taiphoz(Posted 2012) [#19]
Samah : I was wondering you like git over svn why does diddy use an svn repo and not git ?

c.k.(Posted 2012) [#20]
+1 for hg

(Taiphoz, apparently therevills won't let him switch...) :-)

Kalakian(Posted 2012) [#21]
Just saying which one you prefer doesn't exactly help ... I asked why to go with Merc over Git or other way round.

I can easily flip a coin and go with whichever one, but I would rather make an informed decision than leave it up to chance.

ziggy(Posted 2012) [#22]
SVN does do branches
SVN do not do branches, SVN fakes branches and then breaks merging. It has no control on changesets, it just compares files.

Say you move a function from a file to another file, while someone else is modifing the function body. The merging result? On SVN you won't be able to merge properly, and you'll have to repeat everything by hand. (Now try to do this with Tortoise).

On Mercurial or Github, as the changesets are stored, it will know that the function has been moved and ALSO that the function has been modified, and as a result, it'll merge properly. That is, it'll be moved and modified. That's real branching. What SVN does is a bad joke in comparison.

Kalakian(Posted 2012) [#23]
@ziggy not really the point though. I've already decided to look at one of the DVCS because I know svn is limited, but I don't know which one to use. I have came across problems like that before using tortoise, and if using a decent diff tool with it, it is manageable (albeit clumsy).

SVN kinda does branches then ;)

Anyone able to comment on the branching examples that Taiphoz and I gave above, and whether they would work well in Git or Mercurial?

Tibit(Posted 2012) [#24]
I have been on BIG project and merged BIG branches in SVN - it is a Nightmare! I would not wish anyone the same.

I have not done that in GIT or HG, but I'd be much more relaxed branching those since they apparently are built for that. That along with speed is my reason for now moving everything to HG from SVN. Note: I still have most old things in SVN, but I see little reason not to move them over to HG.

On the question "Can you convert from SVN to HG/GIT" - Goto, create and account - import your SVN (you now have a HG copy) and your are DONE with all your source version controlled and backed-up in the Cloud. I have only done that on small projects, but so far I'd recommend it to anyone! I love it so far! Please be kind to let me know if it is too good to be true :)

Paul - Taiphoz(Posted 2012) [#25]
been reading all day long , on merc vs git vs svn .. and found an interesting read that some of you merc and git fans might be interested in,

Its probably where I will end up since it will import my current svn, and can be used for git as well as merc.

dmaz(Posted 2012) [#26]
I went through the same eval process ~2 years ago after using SVN for a decade. I choose bitbucket with merc and have been satisfied ever since.

Paul - Taiphoz(Posted 2012) [#27]
yeah it's not the most popular git def has a bigger community, but thats not really an issue for me, so the free private repositories and its ability to use gir, merc and subversion is what is making me really consider it.

Kalakian(Posted 2012) [#28]
I'll probably create a bitbucket account and start a merc and git repos for a test project, see which one I like the best.

Paul - Taiphoz(Posted 2012) [#29]
I think at this point and after hours of reading blog posts, guides, tutorials and just about everything in between I still feel a little lost when it comes to Mercurial and Github.

But, at this stage I think its a 100% given that I will need to install both as well as keeping subversion in, my only real important decision now is which of the three I am going to use to manage my own code and projects.

Still on the fence, but leaning toward mercurial from what I'm reading it seems the most user friendly of the two.

Samah(Posted 2012) [#30]
@Taiphoz: Samah : I was wondering you like git over svn why does diddy use an svn repo and not git ?

Because therevills set it up originally and he's a Subversion fanboy. :)

ziggy(Posted 2012) [#31]
Maybe we could bring therevils back from the dark side of the force?

therevills(Posted 2012) [#32]

Actually the main reason why Diddy is using SVN is because I set it up before really understanding Hg (and thats the same for Samah too).

I'm reluctant to change now as other users of Diddy will have to change to Hg too...

Paul - Taiphoz(Posted 2012) [#33]
DAMN IT therevills, I was holding you up as MY ONLY!!!!! example of some one who likes subversion, you have just blown up my little thervills bubble... HUH! thanks mate lol

Paul - Taiphoz(Posted 2012) [#34]
I have finally decided to use Mercurial for all my own work, and I doubt I will be changing away from it to anything else now, the similarities between git and mercurial make it that using either is simply a personal choice and not one of features.

That being said there are a few key things that swung this in Mercurial's favor for me, the first is Bitbucket and the fact that it's free for teams of 5 or less, with unlimited space, and unlimited private and public repositories, and that's a major plus to me.

The other thing was that all the guides and tutorials that I read yesterday, and I got through a lot of them, the ones for mercurial all just seemed to be shorter, easier to understand and more straight forward while those for git seemed to be a bit of a dry LONG! read.

I have installed all three systems and will use all three from now on where needed, but for my own projects it will be mercurial that's more dominantly used.

therevills(Posted 2012) [#35]
Remember to commit early and commit often :)

wiebow(Posted 2012) [#36]
HG for me all the way. TortoiseHG and its repository workbench is a godsend.

Paul - Taiphoz(Posted 2012) [#37]
Have to agree I am enjoying it very much.

Still a bit fuzzy on how branches work tho.

Tibit(Posted 2012) [#38]
HG feels so fast, however I'm still a bit lost on how to actually do an proper update.

What I don't get is how to switch current version after doing a pull. I think I get the theory, but not yet the user interface.

And what does "Update" do, if Pull is what gets the data from the server?

I'd love to see a dead simple. Monkey & Mercurial + Tortoise tutorial.

And I'm all OK with you moving Diddy to HG, just write a 1,2,3,4 list of how to get updates in HG :)

Kalakian(Posted 2012) [#39]
I'm working on a document with a simple set of tests for mercurial/git. It's not gonna be a tutorial per se, but it may help ... assuming I can get it working and finished :)

muddy_shoes(Posted 2012) [#40]
What I don't get is how to switch current version after doing a pull. I think I get the theory, but not yet the user interface.

And what does "Update" do, if Pull is what gets the data from the server?

"Pull" brings changes from another repository into your repository. It doesn't alter the working directory files by default.

"Update" brings the working directory into line with a particular revision (the tip by default).

You can do a pull+update in one operation on the command line and most UI clients if that's what you want.

ziggy(Posted 2012) [#41]
In addition to what muddy_shoes says, or to simplify it:
pull :Make my repository aware of any changes available on the remote repostitory
update: apply latest known changes to my local working repository (usualy this merge what's required to be merged)

This is more or less the oposite to commit and push.

Kalakian(Posted 2012) [#42]
I've been doing some experimenting with Mercurial, especially branching, and documenting my findings as I went along. In case it is of interest to anyone, here's what I have so far:

I'll tidy it up a bit, add in my findings using Git for the same experiments, and maybe even turn it into a detailed tutorial ... at some point!

Samah(Posted 2012) [#43]
I'm not sure what your problem is with that first red highlight. I think you might be misunderstanding how branches work. Your local changes aren't "lost", they're simply a different changeset. If you look in the workbench for repository 2, you should see something like this (ignore my keyboard spam commit messages):

Where revision 2 is from the first repository, and revision 1 is the local change that has yet to be pushed. Nothing is lost, it's just not the current changeset. No merge should happen unless you explicitly tell it to. Your head is still in CVCS-land in that case.

Edit: In this example, you would update to revision 2, then right click revision 1 and choose Merge with Local. Resolve any conflicts, then commit. It should now look like this:

2nd Edit: If you push from repo 2, then pull to repo 1, you should get this:

Then update to revision 3, and it should look pretty much identical to repo 2.

3rd Edit: An automatic merge will only happen if you have new/deleted/modified files in your working directory when you update to another changeset.

4th Edit: Note that revision "numbers" are generated locally for the sake of display. The same changeset may have a different revision number in another clone, but internally it has the same ID and the graph should look identical per-branch. Notice here that the changesets with revisions 1 and 2 are in a different order in each repository. This doesn't matter because the changesets aren't related until the merge.

Kalakian(Posted 2012) [#44]
@Samah. The first red highlight is to indicate that things didn't happen as I expected them to, not necessarily that something went wrong. I've been using SVN for years, so there's bound to be some things that don't work the way I expect.

I do find it a bit strange that when I do an update, it just overwrites the changes in my working copy, but not my local repository as you point out. That confused me a bit, which is why I highlighted that bit in red and found a solution to it below, which is similar to yours.

Thanks for explaining it in such detail though, it helps to see what is supposed to happen, for me and others.

ziggy(Posted 2012) [#45]
For anyone coming from SVN it is highylu recommended to read this:

Kalakian(Posted 2012) [#46]
@ziggy I have read that, it's resonably helpful. The bit I didn't pick up on straight away is that you're not given a warning about the merge until you try a push, rather than an update.

Samah(Posted 2012) [#47]
@Kalakian: I expected them to...

Gotcha. :)

@Kalakian: I do find it a bit strange that when I do an update, it just overwrites the changes in my working copy, but not my local repository as you point out.

The term "overwrites" that you're using implies that your modified files have been lost. You should probably think of "modified" as meaning "uncommitted". If you have a clean working directory when you update (ie. no added/removed/modified files since the last commit), all your code is still there, just not the current changeset. It's a strange concept at first, but it's nice to know all your code is safe within one changeset and won't have any weird automatic merging problems when you pull and/or update.

You only need to update to another branch if you want to start working with that branch, or if you want to merge the latest changeset from your own branch into the other.

Paul - Taiphoz(Posted 2012) [#48]
I think I might skip this branching lark until I get more familiar with the basics on it.

The concept seems easy enough bit how its actually implemented and how it actually works seems confusing to me a still, but I will come back to branching like I said, once I have a good basic working understanding and some time spent actually using mercurial and hg.

ziggy(Posted 2012) [#49]
The bit I didn't pick up on straight away is that you're not given a warning about the merge until you try a push, rather than an update.
That's expected. You're mixing two different "push" versions, but it should be perfectly ok. The merge won't overwrite the changes on you last local comit, it'll mix them properly with any other changes done by any other contributor (that's why this kind of things are for :)

Kalakian(Posted 2012) [#50]
Finished running the same tests using TortoiseGit, and have included a summary of significant differences that I noticed between the two of them.

Now, if only I could decide between the two of them, lol

Kalakian(Posted 2012) [#51]
Finally made my decision, I'm going with Mercurial. Thanks to everyone for all the help and suggestions.

I had a look at TortoiseHg's settings (and done some Google'ing) and was able to configure it to better suit my desired workflow. I've taken note of the changes and why I made them in the third version of my test document, just in case it helps anybody else out.

If I do make any more changes to the document, I'll be removing Git and explaining why I'm performing each test, so it may be used as a tutorial ... but in the meantime, I have several projects to convert from SVN, and I gotta setup my Server for Mercurial, and link it into Redmine, and ...

The fun never stops :P

Samah(Posted 2012) [#52]
Kalakian: If you're planning on doing an automatic conversion, take a look at svnsync and the hg convert command. It took me about 30 minutes to do a local read only clone of the monkey touch repository (my work's internet connection is terrible), and less than 10 seconds to do the automatic conversion, which retains changes and commit messages.

Kalakian(Posted 2012) [#53]
@Samah cheers, I'll give that a try. Tibit also said above that bitbucket can convert your SVN repositories, so I'll try that as well, thought it probably just uses one of those commands under the hood anyway

Tibit(Posted 2012) [#54]
Yeah use bitBucket if you can! Works great :)

I'd love to see a step-by-step tutorial on how to deal with Mercuirial and Monkey.

Samah great with Screenshots like that.

However the aspect I feel not sure about is merging, branching.

Kalakian(Posted 2012) [#55]
I avoided conversion with bitbucket since it doesn't retain your history. Samah's suggestion of hg convert worked great though