Git or Mercurial for Embedded Development

[Sal Ammoniac]

I want to upgrade from CVS to a modern version control system. I've narrowed my choices down to two: Git and Mercurial.

I'm a hobby embedded developer and don't collaborate with others on projects. I want a distributed version control system rather an a centralized one (like Subversion) because I develop on multiple machines from multiple places and would like to use github or bitbucket to host my repositories so I don't have to set up and maintain my own server.

For a single developer, which one of these would be the best choice? Since I only work on my own projects, I don't have any need for complex merging of other people's code.

I do all of my development on Windows, and am comfortable with both command line tools and GUI tools and use both interchangeably.

[Monkeh]

git. It's a well proven tool in large scale use.

I have seen a number of projects abandon Mercurial.

[hamster_nz]

I want to upgrade from CVS to a modern version control system. I've narrowed my choices down to two: Git and Mercurial.

I've used Git For Windows and add TortoiseGit (https://tortoisegit.org/) for shell integration (i.e lots of options on Windows Explorer's right-click menu). Works pretty well for me.

[dferyance]

You will get different answers from different people. I have used both. My feelings are that mercurial is simpler and easier to use. So that would be my personal first choice. Git seems to becoming more popular though so having more integrations available may be a plus.

Between the two, I don't think you will regret either. Flip a coin or something.

[Sal Ammoniac]

What IDE do you use? Most IDEs have readily available free plugins for CVS, SVN and GIT.

I use Rowley CrossWorks for ARM. It does support version control systems, but I prefer to do all version control related stuff outside the IDE as that better suites the way I work.

I've looked at GUI clients and SmartGit supports both Git and Mercurial and is free, so I'll probably use that for a GUI.

Is one or the other VCSs better at maintaining the integrity of a repository? I put a lot of time into my code and I'm therefore somewhat paranoid about losing something if something goes sideways.

[Stupid Beard]

I've looked at GUI clients and SmartGit supports both Git and Mercurial and is free, so I'll probably use that for a GUI.

I prefer SourceTree on Windows and OS X, but I use SmartGit on Linux. SourceTree is generally better once you have it setup to your liking; the default setup is kind of retarded these days.

Is one or the other VCSs better at maintaining the integrity of a repository? I put a lot of time into my code and I'm therefore somewhat paranoid about losing something if something goes sideways.

I have used lots of different VCSs over the years, and the only one that springs to mind as one that will screw up your repo is Visual SourceUnsafe. Fortunately that heap of shit has gone the way of the do-do nowadays.

Regarding the original question, Git and Mercury work in a similar manner. I would suggest trying both of them out on a real project and see which you prefer.

[jmag999]

I like Sourcetree as well.  It made it easier to switch to GIT from SVN.  The built-in diff is nice too.

[Scrts]

I've used SVN most of the time, then I had to use Serena, but for personal stuff I vote for GIT . I've tried Mercurial, but somehow it was easier to go for GIT, because I was able to find help more easily.

[rich]

+1 for Git.

Technically either will be just fine for your needs and both have tool support but Git feels like it's becoming the de facto standard for IDEs and cloud based repositories.

Sure my opinion is subjective and based on many years professional dev experience but google trends at least helps enforce my confirmation bias:
https://www.google.co.uk/trends/explore#q=Git%20version%20control%2C%20mercurial%20version%20control&cmpt=q&tz=Etc%2FGMT

Do you use open source libraries or experiment with code examples? If so where/how are these hosted as that may influence your decision? Much easier to grab code with a VCS tool than to click a 'download zip' link.

[Sal Ammoniac]

Sure my opinion is subjective and based on many years professional dev experience but google trends at least helps enforce my confirmation bias:
https://www.google.co.uk/trends/explore#q=Git%20version%20control%2C%20mercurial%20version%20control&cmpt=q&tz=Etc%2FGMT

Maybe that's reason to use Mercurial. We Americans like the underdog.

Do you use open source libraries or experiment with code examples? If so where/how are these hosted as that may influence your decision? Much easier to grab code with a VCS tool than to click a 'download zip' link.

Nope. I write my own code and don't use libraries or examples. One thing I do frequently, however, is create a temporary copy of my code to try something new, which I then merge back into the mainline code if it works out.

[rich]

Maybe that's reason to use Mercurial. We Americans like the underdog.

I can't argue with that logic - I've backed some of those along the way too 

[legacy]

Mercurial: pros && cons ?

(
latin form, I do not know the right English form

PROs=good reasons to use it
CONs=good reasons to avoid it
)

[legacy]

I am using git
PRO: cause I have to follow the linux kernel development (especially for MIPS), and those guys have decided to use git for all their repos
CON: my list_CON[]={} is empty, however I have no experience with SubVersion and Mercurial

[legacy]

Maybe that's reason to use Mercurial. We Americans like the underdog.

My urban dictionary says that an "underdog" is a person or group in a competition, usually in sports and creative works, who is popularly expected to lose.
so the question is: actually, why do you use ? (do I miss something ?)

Correct me if I am wrong with the above term meaning, I am not American, in my wishes: to understand and learn slang and urban dictionaries.

[nfmax]

My urban dictionary says that an "underdog" is a person or group in a competition, usually in sports and creative works, who is popularly expected to lose.

In days of yore, men (it was always men) had to saw up very large logs by hand, as there was no other way. Because very large logs are very heavy, rather than lift the log onto trestles, they used to drag it over a hole in the ground - a sawpit - where they wanted to cut it. Then two men would take one end each of a very long saw, and push & pull it between them. One stood on top of the log, or on a stand, the other was down in the sawpit. These positions were called 'top dog' and 'underdog'...

[gmb42]

While git is what the cool kids use, for someone with cvs experience you will suffer at the start with the different vcs model, so you may still want to consider svn.  Mecurial tries to take the svn model and apply it in a dvcs fashion but seemed to me to fall between the two stools.

IME all git newbies will trash their local repo at some time, and then make things worse trying to fix it with all the random websites offering recipes with all the many different git commands and options.  This is especially painful if you haven't pushed your only copy of work to another (hosted) repo for a backup.  git encourages a "keep work local" model with very handy local branches, whereas svn branches are a central server equivalent that require a little more effort to switch your working copy between but a somewhat harder to inadvertently destroy.

There are plenty of folks that host svn servers, some for free, so I don't see that as a differentiator.

If your mind isn't made up yet, I would suggest svn first, then if you don't like it, or need more, a migration to git is possible, whereas going in the other direction is a lot more difficult.

[Monkeh]

cause I have to follow the linux kernel development (especially for MIPS), and those guys have decided to use git for all their repos

It was written specifically for the task, actually.

[savril]

While git is what the cool kids use, for someone with cvs experience you will suffer at the start with the different vcs model, so you may still want to consider svn.  Mecurial tries to take the svn model and apply it in a dvcs fashion but seemed to me to fall between the two stools.

I don't understand why you think Mercurial is like the svn model. Mercurial is truly a DVCS with a local repo and push/pull fashion with cheap branching. For me git and Mercurial are on par with the DVCS model.

A few years ago for a IT contract as an architect, I choose Mercurial for VCS because it was way simpler to use, and developers were not accustomed with DVCS. Git as a lot of functions that few will use. The terms used for the commands are somewhat disturbing. The flow is more complicated (stash, commit). The number of users is way beyond git (1/10 I would guess).

But git has more users and most OS projects use it. It was built to manage the Linux kernel source, so it can manage very large repositories. Github is also a major reason to use git, not because of Github but because a lot of people use it and it facilitate the job when you contribute patches to an OS project. But to use it, I have to keep a git manual at hand to remember some functions I use only sometimes. You will also crash a least one time a repository because you will have wrongly used a dodgy command. I really don't like the CL UI.

I like Mercurial more than git because its flow and syntax is way more intuitive than git. And I like its code better as it is written in Python than in C for git, it give it a possibility for more extensions.

But if I would have to choose a DVCS for a company, I would go for git as it is really more widely used. Git has integrations in all the (not outdated) tools, like Subversion or CVS. When working with other people (contractants, open source contributors, ...), you are most likely to find people who already know git than mercurial.
Git is now the de-facto standard.

But in your case as you don't work with others, I would choose on :
- how much the tools you use have integrations with git
- how important is the community support for you, as Mercurial has less users

[gmb42]

While git is what the cool kids use, for someone with cvs experience you will suffer at the start with the different vcs model, so you may still want to consider svn.  Mecurial tries to take the svn model and apply it in a dvcs fashion but seemed to me to fall between the two stools.

I don't understand why you think Mercurial is like the svn model. Mercurial is truly a DVCS with a local repo and push/pull fashion with cheap branching. For me git and Mercurial are on par with the DVCS model.

I mistyped, I meant that Mercurial commands are similar to svn commands, which are somewhat similar to cvs.  Thus Mercurial commands look at first glance to be the same as svn, but of course they're working on a dvcs repo so "unexpected" things can happen.

I always see "cheap branches" quoted as a pro for git.  Svn branches are also cheap, although a bit more wordy "svn cp path/to/repo/trunk /path/to/repo/branches/mybranch -m "Your commit message here", and all the action happens on the central repo where a shallow copy is made.

What is more "expensive" with svn is switching between branches, as all the differences between your current wc location in the repo and the new branch have to be pulled from the central repo.  With git, this all happens locally in your repo as git trades local disk space for bandwidth to the central svn server.

[nctnico]

I like to use version control from the Eclipse IDE because it is well integrated. It is very helpful to be able to see the difference between a previous / trial version and the current code or to just look at the differences between 2 versions. Copying & pasting between actual code and old code is also very easy.

[zapta]

Git has very non intuitive command set but is the de facto standard. Practically you need to remember only very few commands and search the web for occasional more complex use cases.

[Cerebus]

My 2 pence worth.

Over the years I've used most of the various standard version control systems from SCCS onward. In a toss-up between git and Mercurial I'd opt for Mercurial every time. The everyday things you need to do with a version control system seem a lot easier and more straightforward to achieve with Mercurial - git always seems to need an option added to the command line for even the most straightforward of tasks.

In terms of absolute capabilites they are about equal; it's just in my experience that Mercurial doesn't get in the way of getting the task done
.

[Karel]

..., so it is painful to use git with schematic files, ...

That depends on which software you use for schematic design. EDA software that uses textbased/XML formatting for their design files go very well with git.

[westfw]

Nice "class" on GIT (and on vcs in general.  People already familiar with some vcs may find it a bit slow):  https://www.udacity.com/course/how-to-use-git-and-github--ud775

[magetoo]

I'm using Mercurial for some personal projects, mainly because there was a good tutorial for it.  Git, anecdotally, seems much harder to learn and to really understand.  (In my small sample size of friends, the process of learning seems to be typing "how to X in git" into a search engine and trying suggestions until something works.)  Not such a big deal once you're up and running though.

Fossil could be worth investigating too.  Pros: One small binary does everything, repos are single files, integrated wiki and web support.  Cons: Small user base, the idea of a "fossil record" might not be the right one for everyone.