Git and Hg accomplish essentialy the same thing.
The platform support and tool/utility support for Mercurial on windows in important to note.
I decided to choose Mercurial as the VCS for my 'work'. This was a team that had no prior exposure to VC before. And works in a mixed environment.
Hg follows the 'one true way' philosophy of Python; so there's just a single command to learn for each task.
Plus, Bitbucket's new Free pricing plan for tiny teams convinced me to go with it for online hosting(rather than roll our own hg server over vpn)
Though, If I had to choose a host/vcs for 'my awesome FOSS community project', it would go on Github.
This is basically where I stand as well. Git has no real appeal for me, but GitHub does. Plus, with the ridiculously easy hg-git[1] tool, I'm able to take advantage of GitHub while staying in my Hg comfort zone :)
Heh, I'm the exact opposite. I use a hg-to-git tool to access hg repositories, because I'm much more comfortable with git.
I often hear people claiming hg is easier to use and has a better interface, but every time I have to use hg it rubs me the wrong way because I can't use it like I use git :/ (In particular, I find hg branches needlessly complicated and cumbersome compared to git's "just a pointer" model)
I guess between the two you'll end up using the one you first bother to learn beyond memorising basic commands.
No specific commands really, but I think the whole hg UI is just more consistent. I use both, yet with git I have to revert to `man` almost every day :/
Compare: `git branch xxx / git branch -a`, `git tag xxx / git tag -l`, `git show-ref --heads`
To: `hg branch xxx / hg branches`, `hg tag xxx / hg tags`, `hg heads`
There are also "duplicates" that I'm not sure why aren't folded into one command: `show-branch/branch`, `show xxx` which is `diff -c xxx` in many other systems, etc.
These are just simple cases, but there's loads of situations where you have to find out yet another command in git / yet another parameter to do what you want. Hg has better defined defaults and the whole list of commands looks like it was designed, while git looks like everyone just added what they needed... Auto-expanding commands in hg is also nice - I hate it when git tells me 'ci' or other short name is not a command (yeah, I know about aliases).
In some situations I also think that git does exactly what it's programmed to do... which isn't always the same as - what workflow makes sense in a specific case. For example `branch` creates a branch, but you still need to do `checkout` (or just `checkout -b ...`). Why? What's the common use case for creating a branch you're not going to work on? Which behaviour do you expect more often?
All in all, not the end of the world, but when you use the tool every day, it becomes annoying, especially if you see it can be done better.
There have been times that I've created a branch just to have a stopping point to which I can go back, but I wasn't going to do any work on it, at least not yet, like two choices on how to re-factor something, try one, if it fails try the other, but keep both around for testing.
There is a subtle difference. git-show is meant to show an object. A commit is an object, but so are other things. A more descriptive name would be 'git show-object.'
An example that I just came across in normal usage:
git show <branch_name>:<filename>
This will show you the contents of <filename> on <branch_name>. It does not show you the diff of that file for the latest commit to <branch_name>; it spits out the state of that file to the $PAGER. This is something that 'git diff' does not do. Note that <filename> doesn't even have to exist on the current branch, and you don't even have to have a working tree (i.e. you can do this in a bare repo to inspect file contents without actually needing to checkout a working copy of all of the code).
I use both git and hg - and like both of them (though I have more experience with hg). Github is far and away the best hosted distributed version control service, with a constant stream of innovative features for open-source developers over the last 2 years.
Git has had two main drawbacks in my mind. 1) Much of it is implemented as script commands, and I think it still requires you run an emulated shell in Windows to use it (by contrast, Mercurial is a pure python app, and is ultra-portable). 2) Coming from the Linux community, it seems a little heavy weight for small projects. Some command require what seem like extra steps on Git as compared to Hg. For example, Git requires that you do a "git add" before doing a "git commit". Mercurial assumes that you want to add all the changed files in your repo (or you can list the files needed in a commit).
For complex scenarios, Git's system does provide a bit more control in packaging up exactly the set of changes you want in each atomic revision.
Besides these minor historical differences, I think they both are excellent, and are really a matter of personal or team preference.
Git requires that you do a "git add" before doing a "git commit". Mercurial assumes that you want to add all the changed files in your repo (or you can list the files needed in a commit).
This is one of the features of git I most appreciated when I started using it (my first VCS was Mercurial).
I get distracted easily. While I'm rooting through the code base trying to do something, I'll notice something else to fix. And something else. And something else. By the time I've finished whatever I was trying to do in the first place, I've got 5 or 6 different things I've actually done.
In git, it's trivial to split these up - `git add` separate files, or `git add -p` when you only want to stage some of the changes in a file. This leads to cleaner commits.
I've heard people decry this, saying that you should be testing each individual state of your codebase. git being the powerful sonuvabitch it is, you can do that:
* `git stash --keep-index` will store away all of your modifications, other than the ones you're getting ready to commit. Run your tests, commit, `git stash pop`.
* Checking out different revisions and running tests isn't a bad option, either, whether you use `git bisect` or do it manually. With the amazing power of `git rebase -i`[0], you can easily fix any little issues without disrupting other commits.
You will change their SHA1 sums, so they'll become different commits. This isn't a problem, though, if you haven't pushed them up to a shared repository.
The differences on commit both have good arguments. hg is going for ease of use and is very much like the non-dvcs's that came before it, like CVS and Subversion where a commit commits all changed files.
git add just adds the file to the index and stages it for commit, this means you can group files logically depending on what has changed, you can even using git add -p have only certain parts of a files modifications be committed and the rest be staged for the next commit. This can be very powerful.
For example, if I did a full refactoring of a class, and fixed a quick bug rather than committing them both at the same time in the patch I can just keep the bug fix and then later commit the re-factored code even if it is in the same file.
Exactly. And if you know that you just want the SVN/HG commit-everything, just add a -a. Pretty intuitive.
Once you get used to having the ability to create arbitrary commits from a huge changeset, you'll find it aggravating when everyone else commits "3 bug fixes to core, swapping out a style sheet, and cleanup in database code" :)
Unfortunately people working with git at work are still doing exactly that. Not sure how to make them stop either, since so far telling them it is wrong hasn't helped ...
You know, comments like that disparage by implication anyone who finds value in PHP or SVN. That's a big chunk of the development community. It tears people apart rather than bringing them together. Maybe you should redirect your energy from snark and criticism toward something more constructive.
You can simultaneously find value in something, and have a sense of humour about that something's shortcomings. Learning to laugh at ourselves is probably the greatest thing humanity could do to further peace and happiness.
That's a fair point, when it applies. But I perceive this joke as coming more often from a sense of superiority and an emotionally ill-conceived attempt to improve others by insulting them.
Why is PHP not a "real" programming language? Why is subversion not a "real" version control tool?
Yes, I've programmed in PHP and know it has some downsides, and that it has some big warts that are ugly, but it is a real programming language. Real projects are built with PHP.
Now I understand the frustration with Subversion, but it still is a version control system that is used in the real world. Would I love it if everyone decided to move away from SVN and onto something more capable like Git or Mercurial, yes, but that doesn't mean we have to belittle people who are using those tools.
I wasn't going to jump into this discussion but that isn't very fair. I don't use PHP myself and am not a fan of it but here are some reasons why I think it is popular:
1) It's very easy to get started with, even if you're not a great programmer (or even if you have never programmed before). Just start with pure HTML and then add a few <?php> tags.
2) Lots of PHP hosting available, much of it free.
3) Loads of frameworks and libraries available.
If "real programming language" advocates spent more time creating equivalient/better alternatives to projects like Drupal or Wordpress in their preferred environments, they'd advance their goals much more than any HN/Proggit comment could.
PHP developers can probably take comfort in the fact that much like Java, Perl, C, Snooki, and others, even though PHP is long past its "sexy" stage, it's well into its "many billion-dollar companies are built on this" stage.
SVN users, well, they probably just don't know any better. :)
The ERP where I work wraps RCS with a bunch of scripts. It's used for source control (of course) but also schema migrations, source generation, and a million other things
I've checked files out that were last modified before I was born.
Because both are commonly perceived as a step backwards from the current state of the art, but more importantly because it's good sport to make cheap jabs at both of them :P
That is an excellent choice for them. Dr. Hipp (author of SQLite) is the author of Fossil and a big Tcl fan. Tcl is maintained by a small core team of developers. Just an overall good fit for them.
The C Ruby implementation is actually on subversion with an official git mirror. Granted, most Ruby projects are hosted using git repositories these days.
There is a reason Python is paired with Mercurial.
Hg is written in Python. As for why Mercurial was chosen over Bazaar, it came down to popularity. As the core developer survey shows, hg was preferred over bzr.
Java is a specification, the Oracle JRE/JDK is not open source. The OpenJDK uses Hg. When they talk about Python they are talking about the cpython or main implementation. Pypy, another Python implementation uses Hg as well
Interesting to note that bzr got close to mercurial in the votes in spite of this being bzr version 1. Version 2 is much improved in speeds (comparable to git/hg).
I would be interested to know about other's impressions of bazaar and why most people seem to share the same sentiment towards it as those at pycon that year
While no one said they did not want bzr chosen, no one said they did either.
I did detailed evaluation of bzr, git, hg and svn. And found bzr to be good too (at least equally good). Most comparisons I found online have been too old to be using older version of bzr which was very slow in comparison.
I am still unclear on the impact of a "branch" being the key concept in bzr as opposed to "repository" in git/hg.
Git's support on Windows has improved considerably (although I could not find a good GUI). So I rather find not much reason to use Hg!
In all fairness, I'd like to point out it's quite possible to make Git work on Windows. If one can adjust the path, it is also reachable through the same command line Windows folks are used to.
Quite possibe to make work and works equally well are not the same thing. Mercurial is a breeze to install on Windows and any other platform, and with TortoiseHg's recent move to Qt, full cross-platform GUI support is also there (right now there are no Mac installers, but there should be some soon).
The last time I looked, Git on Windows required you use a different shell than the native Windows command shell (not that I'm a fan of the crappy Windows shell, but it does make it more awkward and feels less "native").
I've been using MsysGit (Windows) for about 18 months as a "local vcs" wrapper around a sucky vcs (Accurev). Until the most recent MsysGit release, I used the "git bash" shell exclusively: for each Accurev workspace, I had a CMD shell where I ran builds in the w/s, and a git bash shell where I operate git for that w/s. This was mostly satisfactory (being able to write true bash scripts to automate git a tiny bit was cool), but when working with sometimes a dozen or more workspaces, it can get a little time consuming to locate the respective shell's mate. Anyway, MsysGit has mostly worked quite nicely for my limited purposes. However I am now evaluating hg as a possible replacement for Accurev (I'm running a quasi-import over the weekend). I'm also running a git import in parallel (mostly to compare repo size growth over time), and to do that (in lockstep) I'm running git from a CMD shell; so far I've not had any problems using git in CMD (wait, git's interpretation of the %EDITOR% environment variable in CMD is broken). Why hg, after all my experience with git? As mentioned elsewhere in this discussion: MsysGit (git for Windows) is like a "second class citizen"; it's pretty clear that the git creators have a negative religious attitude about Windows, thus expecting equal functionality and support on Windows is folly. The MsysGit discussion threads reflect a shoestring operation, with overwhelmed developers solely scratching their own itch (fair enough as far as it goes). Whereas hg treats Windows as a first class platform (presumably because it was designed and built with that in mind). I still like git's branching feature (which is why I chose it initially over hg), but between hg and git, hg is IMHO the only pragmatic choice for a "Windows shop".
I think it's called Git Bash. It isn't so bad though, you get some working Unix commands with it. Come to think of it, I think it's better than CMD, to an extent.
I find the way your phrase that question interesting. Git and Mercurial are nearly identical in terms of functionality, to the point that converting back and forth between them is pretty trivial. (Example: here's Git's repository in Mercurial https://mirrors.kilnhg.com/Repo/Mirrors/From-Git/Git)
The only real difference between the two are the ecosystems. Mercurial, being written is Python, is very portable and easily extensible. I feel like, because of that, the tools for Mercurial are better. Git has GitHub, and the incredible open source community they've developed there.
* Note, the rainbow road is due to one of the few differences between Git and Hg: Hg does not allow octopus merges, so the conversion turns them to a sequence of two at a time merges. Also, in the interest of full disclosure, I'm one of the devs on Kiln, so I'm certainly biased towards Hg.
Relative occurence numbers don't say much about the need for octopus. Maybe they're rare but when the need arises it proves to be an invaluable feature.
`histedit` does what `rebase -i` does, `hg rebase` does what `rebase` does.
There are a few limitations to `histedit` compared to `git rebase -i` I think: I believe it's possible to split revisions using `rebase -i`, I don't think that can be done using histedit (it has pick, edit, drop and fold). Histedit also misses the (pretty recent I believe) `exec` action of git's rebase -i.
hg branches are entirely different from git branches, so resetting them in that way doesn't make sense. The closest approximation - bookmarks - can indeed be reset (hg bookmark -f).
histedit does a variety of things; I'm not sure if it covers all of rebase's branches. Mercurial does also have a rebase facility now as well.
Hg seems to have evolved several vaguely similar but isolated optional features (named branches, local branches, bookmarks, patch queues) which I guess means they haven't arrived at one everybody's happy with. Some people even prefer to keep hg branches in cloned repos, which sounds very painful. Git handles all those use cases by binding a ref to a commit and calling it a branch (even stashes are stored as branches, just more difficult to push).
> histedit does a variety of things; I'm not sure if it covers all of rebase's branches. Mercurial does also have a rebase facility now as well.
That is correct. In Mercurial, git's `rebase` is (sensibly, as far as I am concerned) split into two different commands: `histedit` handles the history edition within a branch and `rebase` handles the rebasing of a branch on a revision of an other branch.
While mercurial being written in python is noted[1] , it is made explicitly clear, its not the reason behind the main selection of Hg as the version control.
"First, git's Windows support is the weakest out of the three DVCSs being considered which is unacceptable as Python needs to support development on any platform it runs on."
This is FUD! The support for git on windows is pretty good and there is nothing obstrusive in it. You can use git on Windows fairly well. Sad to see this kind of comment written by smart people.
Git's Windows support is clearly the weakest since it requires either MinGW or Cygwin. The platform itself is unoptimized for native Windows performance. It may not be terrible but it's certainly the weakest of the DVCSs, as they say.
Last time I tried TortoiseGit, adding a file either didn't work or just crashed hard. Mercurial, on the other hand, just got TortoiseHg 2.0, which is a pleasure to work with.
It is true that git works on Windows, but that doesn't mean it works well.
I've been working on a prject last year which involved a few developers using Windows.
It was a nightmare. Myself using Linux, i had no problem.
But git on Windows..
It'd definitely behind other VCS.
Trolling aside, that's the only reason I chose hg over git for my projects -> sane approach to the UI. With both of them having more or less the same functionality, UI of git is... inconsistent at the very least.
http://mail.python.org/pipermail/python-dev/2009-March/08793...
But I see from http://www.python.org/dev/peps/pep-0385/ that it's taken that long to migrate away from svn.