I use Git at work because Git is the team's choice. However, I prefer Mercurial for my personal projects. It's not a secret that Git and Mercurial branching models differ, and bookmarks in Mercurial are like branches in Git. I really like Git branches and use Mercurial branches rarely, just when I really need it, preferring Mercurial bookmarks. However, I miss something like git branch -d in Mercurial, because deleting a bookmark in Mercurial removes the bookmark only and preserves the immutable history. Is it possible to drop a bookmark in Mercurial with all of its changesets to the changeset where the bookmark has been diverged from?
In general:
hg strip revisions_to_drop
For your problem:
hg strip 'not ancestors(heads(all()) - bookmark(name_of_bookmark))'
(i.e. "strip all revisions which are not ancestors of heads other than the bookmarked head")
Assuming a sufficiently recent version of hg:
hg strip -B name_of_bookmark
Related
I cloned a project to my local directory and made a lot of changes. My current goal is to push my changed code to a new branch in the remote repository. And eventually this new branch will be merged back to default.
My problem is, because of some stupid effort in the past a few weeks to try to recover some missing files, I end up with a few branch names that I don't want being shown in public.
Here's what I have:
$hg branches
dev-v02 197:xxxxx
dev2 194:xxxxx
dev 183:xxxxx
qa 189:xxxxx
$hg branch
dev-v02
My question is, if I push my current branch dev-v02 to the remote repository by "hg push --new-branch", and this branch later get merged back to default, will the unwanted branches show up in history of default? And if so, is there a safe way to purge them?
I do NOT want to discard my changes. I just don't want the unwanted branches showing up in "hg branches" or "hg his" commands by whoever later clones the project from the remote repository. I searched online and found "hg strip" but I couldn't tell from the article if it would also remove the changes I've made. Thanks.
Edit: I just cloned my local repository by "hg clone -r 197 original-dir dest-dir" as suggested by both kevin and chessbot and now hg branches shows:
dev-02 192:xxxxx
qa 187:xxxxx (inactive)
I guess "qa" remains because I had pushed it to the remote as a QA branch and closed it later, and I just have to live with that. I will push from this new directory from now on. Thanks guys for your help.
Try hg push --new-branch -b dev-v02 to specify that you're pushing only that branch.
(See: https://www.mercurial-scm.org/repo/hg/help/push)
Another thing you could do: Clone the repository locally on your machine, strip out the branches you don't want, and then push that clone to the server. Then you retain your history locally without pushing it to everyone else.
It depends.
Branches are permanently associated with a commit. The branch is part of the commit, and contributes to the hash. Changing the branch of a commit in the past would alter all commit hashes from that point forward. This is quite different from Git, where a branch is little more than an ephemeral pointer to a HEAD. Such pointers are implemented in Mercurial as bookmarks.
If the unwanted branches appear on commits which are (ancestors of) commits you want to publish, there is very little you can do, short of recreating the history with all-new hashes. This could (for instance) be done with hg export and hg import, along with local cloning and (probably) a certain amount of shell scripting. More efficiently, you could use the convert extension to automate the process. Since this changes commit hashes, it will likely cause serious problems if any of the commits have already been distributed publicly.
If you have no interest in sharing the offending commits, you can simply not publish them. This can be done with selective pushing. However, since you'll always have to manually exclude those commits every time you push, it's probably safer to clone and strip (or clone selectively with the -r flag). You can then push from your partial clone with impunity. Assuming you have a sufficiently recent version of Mercurial, you can also force the commits into the secret phase, so that they will not be pushed:
hg phase -fs revisions
You don't want to use hg strip, because it permanently removes the commits from the history (see Editing History in the Mercurial wiki)
If I were you, I would close the branches instead:
hg up -C badbranch
hg commit --close-branch -m 'close badbranch, this approach never worked'
hg up -C default
(source: Pruning branches in the Mercurial wiki)
After closing a branch, hg branches doesn't show it anymore.
If you do want to see closed branches, use the -c parameter:
hg branches -c
Disadvantage:
hg his still shows closed branches.
You could use the -b parameter though, to show only the default branch:
hg his -b default
In our workflow we are using Mercurial mq for our development the default branch. However, when we need to merge another branch into the default, what is the best practice to apply these patches on top of the merged default?
Obvious (ugly) way: pop all patches, merge branch then push all patches and fix all the .rej files...
Correct way should be to use rebase somehow but not sure what's the correct workflow.
Any ideas?
I think hg rebase --mq might do what you want. If not, try this:
hg rebase -s qbase -d default
The rebase command itself is aware of Mercurial Queues, at least in semi-recent versions of Mercurial.
See the rebase documentation, mention of this feature in the MQ documentation, and somebody's blog post.
In short, you can rebase applied MQ patches like you would any other set of changes, and rebase is smart enough to make sure they remain as MQ patches afterwards.
Currently my company is using cvs for version control. We have an old branch of code which has been used specifically for one client (don't ask) that we'd like to merge to the head.
Due to the delta between this branch and the head I think the merging capabilities of mercurial should make my job a bit easier. My line of reasoning is:
Create mercurial repositories of the branch and the current head.
Do a merge of the branch repo to the trunk repo.
At this stage I'm expecting mercurial to provide better merge support than cvs.
Then I would commit my changes to the trunk repository back into cvs.
Is this approach sound? Will this strategy result in a less painful merge as I think it will, or is there something I'm missing?
The reason Mercurial merges better than CVS or Subversion is because it tracks the most recent common ancestor of the two heads/branches, so you'll to make sure you're providing that information accurately or you'll probably end up with a worse merge.
If you do something like this:
hg init newrepo
cd newrepo
cvs checkout POINT_OF_DIVERGENCE
hg commit --addremove -m 'commiting point of divergence'
cvs checkout BRANCH
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'committing branch head'
hg update -r 0 # jump back to point of divergence
cvs checkout HEAD
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'commiting HEAD head'
hg merge
then the common ancestor for the two heads will be the point of divergence (sorry if the CVS commands are wrong, it's been a mercifully long time).
The trouble is knowing where the POINT_OF_DIVERGENCE is in the CVS repo -- CVS doesn't keep track of that at all, which is why its own merge doesn't use it.
CVS best practices always suggest that whenever you branch you create a tag that marks the point of divergence, but if you didn't do that then there's some tricky hunting ahead of you.
Without a correct most recent common ancestor the Mercurial merge won't be any better than CVS's.
Yes, that should work but there might be tiny little problems along the way (like how to get the source from CVS into Mercurial: Using hg convert or doing a manual import of a certain revision, etc).
Please create a new question if you run into a problem.
The built-in convert extension won't do well with CVS except for very simple histories. Use the fork of cvs2svn called cvs2hg
http://hg.gerg.ca/cvs2svn
I am using hg-subversion, and I have 2 different hg repositories one from our svn trunk, and one from a branch of the trunk. I would like to link them somehow. At some point in the history both Hg repositories will be identical is there some way to join them?
In other words is there a way to relate the repositories from within Hg?
The technique I am currently using is to just export the second repository over top of the working copy of the revision they share, and then commit that working copy as a branch in Hg, but I lose the history this way.
Any advice would be great
You could try importing the two repos into one as if unrelated, then merging them. (When you say they share a common ancestor, do you mean that those ancestors have the same revision ID? If so there is a good chance that this will work well.)
hg clone repoA
hg pull -f repoB # may not need -f
hg merge
Can you re-clone the Subversion repository, giving the root of the Subversion repository as argument instead of trunk or one of the branches? I used hg clone svn+ssh://foo/bar/baz once, where svn+ssh://foo/bar/baz/trunk was the trunk and svn+ssh://foo/bar/baz/branches/quux was a branch, and in the end I had two named branches in Mercurial, the "default" branch representing Subversion trunk and the "quux" branch representing the like-named Subversion branch.
If you have outgoing changesets in your existing hg repos, you might be in a bit of a bind there. If there are just a few outgoing changesets, it might work to enable the mq extension and to convert the changesets into patches. These patches can then be re-applied on the new clone (in the appropriate named branch) and eventually pushed to Subversion.
We're using Mercurial where I work and I want to have a setup similar to how I used SVN:
Trunk
Tags
Production
Branches
Since Mercurial supports branches natively, I know how to create a named branch, but I can't find any documentation on how to repeatedly merge 'Trunk' with 'Production'.
Quite simply, I want to have a development branch for normal work and a production branch that I routinely pull changes from the development branch into. How do I do this with Mercurial?
As the previous poster mentioned, the transplant extension can be used for cherry-picking individual changes from one branch to another. If, however, you always want to pull all the latest changes, the hg merge command will get you there.
The simplest case is when you're using clones to implement branching (since that's the use case Mercurial is designed around). Assuming you've turned on the built-in fetch extension in your .hgrc / Mercurial.ini:
cd ~/src/development
# hack hack hack
hg commit -m "Made some changes"
cd ../production
hg fetch ../development
If you're using local branches:
hg update -C development
# hack hack hack
hg commit -m "Made some changes"
hg update -C production
hg merge development
hg commit -m "Merged from development"
Something like hg transplant? That's what we use on our dev and prod branches.