Case in point: Lets say that you want to change the username on all your previous commits. I've needed to do this several times for various reason.
git filter-branch --commit-filter '
if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
I believe services like GitHub or Gitorious is a big factor. It's important for people that they can host their stuff somewhere and especially GitHub is a great service for that.
For mercurial, there was no such service when DVCS became popular (at least none I was aware of). You have Bitbucket now and probably others, but GitHub has been there for quite ...
I see a lot of answers to this that rely on the feelings the author had when hearing about one or the other SCM. Others say it all was sheer luck. I believe luck can be traced back in history.
I will talk about history.
Git and Mercurial were created simultaneously in order to solve the same issue. Back in those days, the Linux kernel was forced to stop ...
As you describe it, you already have some sort of version control, though currently there are some issues with it compared to a typical version control:
An intentional commit in version control indicates that the developer strongly believes that the current state of the system would build successfully.
(There are exceptions, as suggested by Jacobm001's ...
Git versus Mercurial
Mercurial is generally believed to be
simpler and easier to learn than Git.
In turn, there is often the perception
that Git is more flexible and
powerful. This is due, in part,
because Git tends to provide more
low-level commands, but also in part
because the default Mercurial tends to
hide advanced features, leaving ...
Linus is a big advocate of Git and promoted it heavily to the core linux group for years and it's grown from there. I daresay it's entirely due to Linus's influence over the *nix community.
Personally I still use Subversion, but that's from preference rather than utility.
Mercurial, without a doubt.
This is of course, subjective, and vaires from one person to another, but the general opinion is that Mercurial is easier to grok, expecially to someone new to VCS or someone coming from one of the old generation VCS's.
Points in hand:
Mercurial was developed with Windows in mind; Git was ported. No matter what anyone tried ...
Just my personal view: Version control is useful for anything that takes me more than half a day or that involves a lot of trial and error – or both, of course. If it involves two or more people who are not using the same keyboard and monitor all the time, it is essential.
The cost of using a formal versioning system, beyond the initial learning curve, is ...
The package "gnuit" (GNU Interactive Tools, a file browser/viewer and process viewer) was called "git" in Debian up until 2009-09-09, while git was called "git-core".
Therefore, a better graph to look at is:
Which shows that the popularity did not rise dramatically (take the green line for the left part until they cross, then take the red line).
Context: I use both Mercurial (for work) and Git (for side projects and open source) on a daily basis. I primarily use text-based tools with both (not IDEs) and I am on a Mac.
In general, I find Mercurial easier to work with. A few things that I find make Mercurial easier:
Lack of the index. The index is a powerful tool enabling many of Git's features ...
if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place. (Of course it's difficult to do when you're doing something fundamentally wrong and silly!)
And therein lies the source of your confusion and the whole problem in general.
You say that merging branches is "fundamentally wrong and silly". Well, ...
Version control was always needed, even before you hacked together your "but, we backup really often!" kludge.
Version control lets you publish those changes across files that belong to a logical function as a unit. If you need to review "what was necessary for case-insensitive sorting in that mask?", it tells you all relevant changes and suppresses the ...
The git package in Debian was formerly known as git-core. In April 2010 the package was renamed to git. More details can be found in this blog post by Julius Plenz or this commit in Debian.
Here is a graph that shows the number installs of both git and git-core over time:
This is very subjective and depends from one person to another, but yes, I would go that to someone completely new to VCS or someone coming from one of the "old school" VCSs, Mercurial will seem easier.
For example, adding files, the non-existence of the index in Hg, the ease of going back to some old revision and branching from there (just update and ...
I was using Darcs for my own projects for a little while. I switched to git during the rapid ascension that your graph is referring to, so here is my observation:
Distributed source control systems at about that time were a bleeding edge thing. The so-called alpha programmers were using them on the side, but they fell outside of the radar of most ...
Instead of saying why git or mercurial is better and saying its the only reason its popular, I'm going to focus on the community.
As I highlighted earlier, the Git community is very loud and arrogant. Most will vigorously defend their precious program. Most of the Git vs Mercurial war's I've seen were started by git people who were wondering why everyone on ...
We actually went through nearly the exact same thing at my company recently. Here's what we did:
We keep a central definitive copy of all our repositories on one server. When developers want to "check out" code, they go to this server and clone from the repositories there. Likewise, when the development cycle is complete, code gets pushed into the ...
The History is sacred, the Present is not. You can split your DVCS "tree" in two parts:
The past/history which contains an accurate view of how you have reached the current state of the code. This part of the history grow over time
The present which part you are currently working on to make you code evolve. This tip most part of the history have about ...
Personally, for your scenario, I wouldn't bother even creating a branch, unless I was working on multiple changes, each of which would need to be accepted by the core developers.
Just clone their repository and work in it, then make a pull request.
If I were to use a branch then I'd rather use named branches. They were designed for this exact purpose, ...
A different tool is probably not going to solve your problem, I'd say you should read this article, I found it most helpful:
I think the main point of the article is summed up here, but please do read it:
In The End: Not Really About The Tools
In all of the time I’ve spent working with ...
Please see my Stack Overflow answer for a very concrete situation where Mercurial (and Git) merges without problems and where Subversion presents you with a bogus conflict. The situation is a simple refactoring done on a branch where you rename some files.
With regard to tdammers answer, then there is a number of misunderstandings there:
It's because svn lacked the proper data structures to accurately determine the latest common ancestor of the two branches. That's not a big deal for a branch that is only merged once, but can cause a lot of erroneous merge conflicts in situations where several branches are merged multiple times.
I don't follow svn very closely, but my understanding is ...
At my company, we use a separate SVN repository for every component of the system. I can tell you that it gets extremely frustrating. Our build process has so many layers of abstraction.
We do this with Java, so we have a heavy build process with javac compilation, JibX binding compilation, XML validation, etc.
For your site, it may not be a big deal if ...
I think the answer is given in the subsequent sentence:
Keeping stable and dev code separate is precisely what source code control is supposed to let you do.
By using #ifdef blocks, you are emulating functionality of a source control system with a C preprocessor. It's the wrong tool for the job.
The downside is that you probably either end up ...
In a similar style to my Git vs. SVN answer, Ohloh has been crawled (only) three times by the Internet Archive's Wayback Machine, but July 2011 is unreadable:
Git: 26,485 repositories (11.3% of total)
Mercurial: 2,548 repositories (1.1% of total)
Git: 116,224 repositories (35.3% of total)
Mercurial: 3,753 ...
There is nothing too difficult about SVN merging... anymore... if you follow the right philosophy
What I see in most other answers seems to come from people who haven't used SVN in a while. As someone accurately mentions: "it wasn't fixed early enough to dispel the myth".
From my current experience of using SVN 1.6 to 1.8 on a legacy project I inherited ...
From my own experience, the following statements are all true:
Git is very efficient in storing text files, and only storing these files that were changed. so when doing a comparison of SVN and Git to compare the repository sizes, they may be similar, or there may be even a small advantage for Git.
This is completely wrong if you compare the size of ...
I think it's as simple as this: Mercurial has a more familiar syntax (particularly for SVN users) and is fairly well documented. Once you get used to the Git syntax, you'll find it as easy to use as anything else.