tags:

views:

127

answers:

2

Hopefully, this isn't a loaded question. I'm a longtime user of hg, and it's meeting our needs quite well. Lately I have been working with a consultant and he keeps going on about 'managing several repos and pushing/pulling/merging them is easier' than hg. More specifically, I believe he means that pushing changes to a remote repo is the easier part. Not really knowing much about Git, I didn't want to tell him there's not much difference. I was under the impression that in both systems, pushing and pulling almost always involved merging if changes from several sources occur on the same file.

Can anyone help clarify what he may mean? His contract ended before I got around to thinking about asking him to expand on what he said.

PS I've read these comparisons and they didn't specifically address my question:

Important Shock: Git vs. Mercurial, Please Relax

Rockstar Programmer : The differences between mercurial and git

Steve Losh: The real differences between mercurial and git

+1  A: 

I think the keyword in his statement, "Managing several repos and pushing/pulling/merging them is easier," is and. In Git, it's very easy to create a bunch of "named" remotes -- remote repos that you can refer to with a name. It's also easy to pull in branches from a remote and keep them in your repo; these branches are essentially namespaced under the name of the remote, so it's easy to group remote branches together and so forth. In other words, it's easy to track multiple remote repos and pull changes from them into your own repo.

I haven't used Mercurial much since about v1.0, so I don't know if this is possible in Mercurial now or not; it wasn't the last time I checked out Mercurial, as far as I know.

mipadi
In mercurial you can add named paths in the `[paths]` section and list them with `hg paths`. Git people often want a way to add them without using a text editor, but adding a line in `.hg/hgrc` or `~/.hgrc` works fine.
Ry4an
Can you store all the state (branches, tags, etc.) from named remotes in an Hg repo?
mipadi
@mipadi, could you give an example of such usage please? I don't know git, but I have a feeling that the closest you can get in hg to what you describe (also have a feeling that it's close enough, but I'm biased :) is to clone the remote repo, then add an entry under `[paths]` of your own repo, pointing to your clone. You couldn't keep remote stuff separate from your own in a single hg repo AFAIK (which I think is what you're saying git can do). But yes, a separate clone would track all remote branches, tags, etc.
shambulator
@shambulator: Let's use GitHub as an example. Say you cloned a repository that has a whole bunch of forks; with Git, I can "name" each forked repo and track them in my own repo (which makes it easy to pull changes in from those remote forks).
mipadi
Ah, thanks - 'tis more or less how I interpreted your answer. Also found [this](http://www.eecs.harvard.edu/~cduan/technical/git/git-4.shtml). Conceptually, git is simpler than I thought...
shambulator
The initial answer plus the comments helped a lot. Thanks guys. Especially shambulator for the link.
raeb
The question spurred me on to learn more about git! +1's all round :)
shambulator
+1  A: 

Take a look at the following questions on SO and their answers:

They are more about branching than merging and managing (access to) remote repositories, but they should help.

Jakub Narębski