CODEWITHSUNDEEP
version-controlmercurialbranch
Matthew Gertner
Matthew Gertner

Reputation: 4537

Keeping the default branch when first commit is to another branch

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")?

Upvotes: 2

Views: 81

Answers (2)

icabod
icabod

Reputation: 7084

I can see two possibilities (taking into account Martin's answer where you are advised to keep default as 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 .hgignore file. 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 null changeset (empties your working directory), then merge into it. This creates a branch called "default".

First we'll do some work on a development branch:

C:\tmp\test>hg init .
C:\tmp\test>hg branch devbranch
marked working directory as branch devbranch

C:\tmp\test>echo something > out.txt
C:\tmp\test>hg add .
adding out.txt

C:\tmp\test>hg commit -m "some work"
C:\tmp\test>hg log
changeset:   0:4631a4a10552
branch:      devbranch
tag:         tip
summary:     some work

Here we have a single commit on our devbranch branch. When the work is complete (which fortuitously in this case, it is), we want to merge the work back into our (non-existent) default branch. So we update to null prior to doing the merge:

C:\tmp\test>hg update null
0 files updated, 0 files merged, 1 files removed, 0 files unresolved

C:\tmp\test>hg merge devbranch
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

C:\tmp\test>hg commit -m "merged"
C:\tmp\test>hg log
changeset:   1:55e879b67c69
tag:         tip
parent:      -1:000000000000
parent:      0:4631a4a10552
summary:     merged

changeset:   0:4631a4a10552
branch:      devbranch
summary:     some work

C:\tmp\test>hg branches
default                        1:55e879b67c69
devbranch                      0:4631a4a10552 (inactive)

As you can see, the branch default is created with the first changeset on that branch having two parents, -1 and 0. After this you would just update to the tip of the default branch when you wanted to merge in - the hg update null would only be done the first time.

Upvotes: 2

Martin Geisler
Martin Geisler

Reputation: 73808

While Mercurial will let you work without a default branch, it's not recommended. Our wiki page says:

Don't use a name other than default for your main development branch

Mercurial's main branch is called "default" and is analogous to "trunk" in SVN, "HEAD" in CVS, and "master" in Git. It is the branch that is checked out by new clones. If you try to use some other name for your "main" branch, users will get a more or less random branch when they clone and commit things in the wrong place, which is generally undesirable.

So you should try to make the default branch your main development branch.

If you want to work in feature branches "all the time", then I recommend that you still make a couple of commits on the default branch when you start the project. Most project need a bit of common setup, so I don't think that will be strange or weird.

Upvotes: 3

Related Questions