35

I use named branches in Mercurial.

In doing so I have created one branch called playground where I can try out various wacky experiments. I never intend to merge this branch into any others and I never want to push it to our main repository.

Since creating it, every time I do a push I am told I have added a new branch and I have to use the --new-branch flag. At this point hg push -b default (or whatever branch I'm pushing) works fine but it's annoying. Is there any way to suppress that message by letting Hg know that I am not interested in pushing that branch ever?

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
George Mauer
  • 117,483
  • 131
  • 382
  • 612

3 Answers3

57

Starting with Mercurial 2.1 (released in February 2012), you can mark your changesets secret to keep them from being pushed to another repository. You use the new hg phase command to do this:

$ hg phase --force --secret .

This mark the current working directory parent revision (.) as being in the secret phase. Secret changesets are local to your repository: they wont be pushed or pulled. Pushing now looks like this:

$ hg push
pushing to /home/mg/tmp/repo
searching for changes
no changes to push but 2 secret changesets

There is no equivalent mechanism in older versions of Mercurial. There your best bet is to create a local clone for the changesets you don't want to push.

Hamish Downer
  • 16,603
  • 16
  • 90
  • 84
Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
  • 2
    There are only really heads in Mercurial, which may be _anonymous_, _bookmarked_, or on different _named branches_. MQ and phases don't give you new kinds of branches, they work with or enhance the existing kinds. – Martin Geisler May 04 '13 at 07:11
  • 1
    I decided to not use phases but just nudge (`push -r .`) bookmarked heads to my own cloned repo. My problem is that its so easy to accidentally push a *head* or merge someone else's *head* with the tools like Eclipse. I don't even use default `paths` anymore because if I accidentally push my feature branch to the main repo somebody will accidentally merge that head. I also don't think of myself as a `git` person but I do feel `push -r .` (aka nudge) should be the default. – Adam Gent May 04 '13 at 14:53
  • In case you're worried if you've got it wrong, you can also use `hg out` to test if you've set it up correctly before you run `hg push`. – Hamish Downer Jun 02 '18 at 13:48
6

Update:

Mercurial 2.1 introduced the hg phase command which allows users to control what change sets are exchanged with remote repositories. @MartinGeisler answer to this question details this method.

Original Answer:

If you want to create a local branch of your code you have a couple options. You can hg clone the repository which will locally create a branch of the entire repository in your filesystem. The other alternative is you can try to use a Mercurial extension like LocalbranchExtension.

There are many ways to branch in Mercurial without using a named branch. Just find a method that suits your needs.

Further reading: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Community
  • 1
  • 1
Dev
  • 11,919
  • 3
  • 40
  • 53
  • I personally don't like this solution, using phases is better than copying your whole repo or scripting your way around, when you do have native support for private branching with Mercurial Phases. – dukeofgaming Jan 07 '13 at 00:24
  • @dukeoffgaming The phase feature was not in a release Mercurial version when this question was asked and answered (Mercurial v2.1 was released 1 Feb 2012). I agree, that using the phase feature with current versions of Mercurial is a better idea. – Dev Jan 08 '13 at 22:24
  • @dukeofgaming forgot about this one, just came back an updated it. – Dev Oct 23 '13 at 16:35
3

In addition to the excellent answer above concerning phases, you can also specify 'default-path' (in the [paths] section of your .hgrc) to refer to the local repository:

[paths]
default = ...
default-push = .

This will cause all outgoing changesets to be compared to the specified repository. In this case, comparing outgoing changesets in your local repository TO your local repository results in nothing to push.

You can still pull/update/merge from the main repository, but no push will ever send anything back to that main repository.

If you work on multiple machines/repositories, you can set one up as described above, and configure the others to specify the 'default' path to point to the server that pushes to itself. In this way, the other machines can push/pull to your local central repository, and these changesets will never escape your carefully configured collection of repositories.

dpmott
  • 282
  • 3
  • 8