CODEWITHSUNDEEP
version-controlmercurialbitbucket
Cypher
Cypher

Reputation: 2697

What is the downside to managing a repository with multiple heads?

I have a project with a single branch, default. I have been iterating on this single named branch for some time now and I have been using tags to mark version number milestones.

The project's source code changed quite a bit between tags 1.0.7 and 1.1.0 (current). However, there are some users on 1.0.7 that need a bug fix. So I checked out the source, updated to tag 1.0.7, implemented a fix and committed. That was tagged 1.0.8, and will probably be the last commit on the 1.0.x line.

I now have two heads on the default branch. I expected that. But when I tried to push to our BitBucket account, I received a warning from hg: "push creates new remote head". Reading up on this message, I get a lot of answers explaining why the message is there and for most people the answer is just to merge. However, I don't think I want that in this case. The two branches aren't compatible.

It looks like I can just use the -f option to force push the new head to the remote repository, however this seems to be discouraged both by hg help and various posts on the web without much explanation as to why. So what is the downside to doing this? It seems as though I can still update to whatever tags/revisions I want to continue working on. If I push that head to the BitBucket account, will I be shooting myself in the foot in some way?

Upvotes: 2

Views: 91

Answers (1)

planetmaker
planetmaker

Reputation: 6044

Having multiple heads is perfectly fine.

If there are several heads and there's little indication as to their purpose, it may be difficult for others to see where they should continue and what is the head which contains the newest developments, e.g. which gains new features.

However by using the tags on the branch with clear versioning like you do, that problem doesn't exist either.

There's one small catch though: Mercurial will, upon clone, update to the newest commit in the default branch - e.g. the head which received the last commit. If that's the 1.0.x head of yours, that might be unfortunate. However you can fix this, by attaching the special '@' bookmark to the mainline or development head. Mercurial will always update to the head which bears that bookmark, if it is present - irrespective which head has the newest commit.

Upvotes: 3

Related Questions