I’ve been using Git for a while, and I’d like to convert my usual workflow to Mercurial. In particular, I’m interested in converting the workflow I would use to contribute to a Git project in order to be able to contribute to a Mercurial project.
Typically, for a project on GitHub, I would fork the project on GibHub from the original project, and then fetch both locally, with two different remote names:
# Clone the initial repository and call the remote repository 'github-origin'
git clone -o github-origin git://github.com/orig_author/project.git
# Add the forked GitHub repo as an additional remote repo ('github-mine')
cd project
git remote add github-mine git://github.com/me/project.git
git fetch github-mine
When I list the branches with git branch -a, I get something like this:
* master
remotes/github-mine/some_feature
remotes/github-mine/master
remotes/github-origin/HEAD -> github-origin/master
remotes/github-origin/some_feature
remotes/github-origin/master
I can create my own local branches using git checkout -b new_feature and then push it back to my GitHub repository, thus adding two references:
* my_feature
remotes/github-mine/my_feature
I can then contact the original author to discuss this feature, submit a pull request and so on.
All this workflow is actually quite independent from the original author’s working time line. This makes it quite easy to discuss experimental features without poluting the main project’s repository.
If the original author has commited more changes, I can keep up with git fetch github-orig and possibly merge or rebase my local changes accordingly. As a quick test (assuming by current branch is my_feature):
git fetch github-origin
git checkout -b temp
git rebase github-origin/master
An essential point of this workflow is to be able to know where each repository’s branch is located compared to my own branches. In particular, it’s important to know that my branches are not the same as the remote branches with the same name (even between the two GitHub repositories, the two master branches don’t need to be the same, for example). Seeing all this is something quite easy using gitk --all.
I’m not sure how to do the same on a Mercurial project (e.g. on BitBucket).
Here is what I’ve tried to do, based on this Command Equivalence Table:
hg clone https://bitbucket.org/orig_author/project
# Edit .hg/hgrc and add 'bb-mine=https://bitbucket.org/.../project' to [paths]
# Apparently equivalent to git fetch.
hg pull bb-mine
This seems to work, and it pulls the remote commits (in fact, I’ve tried this on a repository where I’ve already pushed one of my branches). I can see all the branches using hg branches, but no indication as to where they came from. hg view doesn’t really show anything. More importantly, my tip is now the latest of my commits, but I don’t have an equivalent of the github-origin/master label that I would have (whether it’s before my own commits or it’s after if another author has made more changes).
I would like to be able to do an hg pull (equivalent of git fetch) at any point in time in the future to see what the differences between my local copy and the new changes made by the other author(s) are without necessarily changing anything in my local repository or in my BitBucket repository (at least until I’ve fixed potential conflicts due to those changes).
On top of this, I also tend to have my own backup repository when I use Git (which is an SSH server where I can push all branches, even work in progress that is not meant to be published yet).
I realise that the Mercurial way of branching isn’t quite the same as the Git way. However, is there an equivalent workflow for Mercurial, or will I just have to change my approach? How can I see where each of the repositories I’m using are up to with their respective branches (some of which they may have in common)?
This is a huge question so I’m going to pick a couple of points. I think you should come to the IRC channel or the mailinglist for more advice — I predict that your (further) questions will be of a discussion kind of nature and it’s much better to discuss things there.
Don’t put much emphasis on the
tiplabel. It’s a deprecated concept that means less and less when you have multiple branches. The main problem is that it’s just the most recent changeset in your repository and so it will jump from (named) branch to (named) branch when you pull. We prefer to talk aboutdefaultinstead and other named branches/bookmarks since these identifiers move in more controlled ways.The remotebranches extension might help you get a more Git-like workflow here.
But in general, you should look into bookmarks if you want Git-like branches in Mercurial. The named branches you create with
hg branchbears little resemblance to the branches you make withgit branch(Git lacks the named branch concept of Mercurial).Use
hg incomingandhg outgoingto see the differences between repositories. This is how I normally see what needs to be pulled from or pushed to another clone.