We are implementing a development flow where each new feature has its own branch, which is merged into the default branch when it is completed. The problem is that the very first commit in a new repo occurs in the first feature branch. When it is pushed, the feature branch becomes the default. There is no branch called “default” since there are no changesets associated with that branch. Obviously this is a problem when it comes time to merge the feature branch into the (non-existent) default branch.
The only solution that occurs to me is to have a first commit to default as a convention whenever a new project is started so that we have a branch called “default” that is the parent of all other branches. Is there a cleaner way to do this that doesn’t require a dummy commit (e.g. something that says “commit an empty changeset on default”)?
I can see two possibilities (taking into account Martin’s answer where you are advised to keep
defaultas your main development branch).One Martin has already covered, whereby the first thing you do in a new repository is “initial setup”. Typically this may include your standard template
.hgignorefile. Incidentally I find this to be a better option than…The other option if you have already committed to another named branch is to update to the
nullchangeset (empties your working directory), thenmergeinto it. This creates a branch called “default”.First we’ll do some work on a development branch:
Here we have a single commit on our
devbranchbranch. When the work is complete (which fortuitously in this case, it is), we want to merge the work back into our (non-existent)defaultbranch. So we update tonullprior to doing the merge:As you can see, the branch
defaultis created with the first changeset on that branch having two parents,-1and0. After this you would just update to the tip of thedefaultbranch when you wanted to merge in – thehg update nullwould only be done the first time.