How do I check out a particular named branch of a Mercurial repo?
Ah. I was asking the wrong question.
I needed to know how to switch to a particular branch in Mercurial.
The terminology you've used here is check out.
If you're coming from git, then this means you probably want to set the state of your working directory to whatever is in the particular named branch.
In SVN, you might call this switching. While the answer to this question may be the same, if you ask the same question using git terminology (as you did here), you might not find that answer, so this question is still useful in itself.
In Mercurial, it's called updating: You update the contents of your working tree, like so:
hg update -c <your-named-branch>
The -c isn't necessary, but if you're used to git warning you before anything is permanently overwritten, you'll find it more comfortable. Use -C instead to wipe all local changes, or -m to merge changes.
If you're trying to check out a branch that only exists on a remote repository, you might want to use this instead:
hg pull -u <your-named-branch>
Or else just pull (without -u) first so that the remote branch is brought into your local repository before you use update.
If you prefer git parlance, you'll be pleased to know that checkout and co are both aliases for update. You can also use -r to specify a revision. See the update help page for more detail.
Related
I'm currently dealing with the fallout from BitBucket dropping HG support. We're going to be giving hg-git a try because, while my preference is self-hosting, my boss isn't quite mad enough at Atlassian to move away from BB yet. Taking this opportunity to clean up our existing HG repo before the conversion to GIT. Have used hg convert to remove some accidentally committed binaries to reduce size, etc.
One thing I've noticed is that we've got about two dozen old branches that are technically "open", but have been merged into default (no closing commit, but they're months to years old). Is there any way I can use a tool like hg histedit or during the hg convert to go back and specifically mark old branch heads with --close-branch?
Looking through docs I can find things about editing files, editing the contents of commits, or modifying commit messages, but nothing I can find mentions meta-data around whether a commit is "closed". I know this is just a flag on a given commit, but I don't know how to retroactively add it via any HG extension.
Edit: Just to add a bit more clarity, I recognise I can just update to each of these old branches & add a new commit that just closes the branch. There'll be a lot of dangling-looking, closed heads, but that'd work fine enough. However, I also then have to give each of them a bookmark in HG as well, or these additional "closing" commits are lost in the hg-git conversion. I'd rather avoid having to add ~30 additional branches to the git branch-list, just to have them show up as closed properly in HG without having to use revsets.
What I want to do isn't "essential" in the grand-scheme of the repo, but I'd be surprised if editing a commit's metadata to say --close-branch were impossible.
I tested out the rebase idea with a mock repository and it seemed to work.
Here was the starting repo:
And here was the state after rebase:
I think this example matches what the question was asking about. The original dangling close-branch changeset was moved to precede the merge.
I updated to default and ran the following command:
hg rebase --dest=4 --source=3 --keepbranches --config=ui.merge=internal:merge
I actually used Tortoise Workbench to execute the rebase and that is the command it used. So the final argument for ui.merge is probably not strictly necessary.
As you may have already noticed using hg convert its a really good idea to make new clones when you go to modify the repository. Thus if it gets messed up you have an easy undo option. I'd certainly recommend that approach for this operation as well.
I was surprised when coming back to Mercurial after using Git for quite a few years when I did an hg pull -u: Mercurial fetched the new patches, did a merge without conflict, but still asked for a commit.
Is there a way to automatically commit when a hg pull -u did not create any conflict?
Currently, the revlog is polluted with many "Merge..." commit messages, and I'd really prefer to not see them (although the merge itself should be kept in history in case the automated process makes the wrong decisions).
Nope, I don't think so. This is a fundamental difference between git and hg. Mercurial wants you to make sure the merge was correct, possibly by running your test suite, before committing.
If you don't like merge commits, maybe you should be rebasing your work instead of merging? It's common practice to keep history linear by rebasing feature branches instead of merging.
If you are rebasing a lot, it helps if you make use of the phase system by pushing WIP work to a non-publishing repository and then once code passes review and gets accepted, it gets rebased and then pushed to a publishing repository. You might also find the evolve extension useful, especially if you are working collaboratively with a team, as that will propagate the history editing operations between developers.
you could use an alias for that:
alias hg_pull='hg pull -u && hg commit -m "No Merge Conflict"'
Running hg_pull from your repo should do more or less what you wish.
If anything goes wrong at "hg pull -u" step, the commit is not triggered.
Let me know if something is unclear!
As I understand it, you can't really fix a comment in Hg. So what I would like to do instead is re-push the exact same changes (or at least "touch" the same files and commit & push again).
The reason this is necessary is because we have a bug tracking and build system that relies on specific comment patterns, and we need to make sure the right files get included in the build, but if I forget to update the bug # in my comment from my last commit, and I accidentally commit and push it under the wrong # because i'm overzealous, how can I re-push those same files again without manually going into each one and adding a space or line break just to create a diff?
To clarify, I can't "rollback" or something; it's already been pushed with the wrong message.
As far as I know, current Mercurial features provide no support for this. After the changeset has been pushed, there's little you can do to un-push it, besides stripping it from the server repo and any other developer's repo.
I guess you you should ask those who set up this workflow in your shop; they should've come up with some exception handlers for it.
We usually just ignore issues like this, and close the bug by hand, making sure the bug links to the correct changeset. If the changeset is really messed up (usually this means bad changes, not a malformed commit message), we resort to stripping.
Since your change has already been pushed you can't use a simple fix, like "hg commit --amend", but you can do something similar. Basically, the following commands re-do the commit with Mercurial's help:
CSET=...the changeset to re-do...
hg up -r "p1($CSET)" # Update the working directory to the parent revision
hg log -r "$CSET" -p > changes.patch
hg import --no-commit changes.patch
hg commit # And use the appropriate commit message.
Then, merge and push.
The only way that I could think of doing this is to commit two more changes, one would be an hg backout of the incorrect revision and the other would be an hg backout of that revision with the corrected comment.
I don't like that idea though and wouldn't recommend it if there was any way to fix the problem in your bug tracking system.
Like the title says. I essentially want a way to make Mercurial "forget" a changeset in the local repository. Obviously, this would only work for changesets which had not been pushed without also reverting the original changeset.
Mercurial doesn't make forgetting anything easy -- no commands that are destructive of history are enabled by default. Without enabling any extensions the easiest way to do this would be:
hg clone -U -r LAST_CHANGE_YOU_WANT your-repo new-repo
and then replace the .hg in your-repo with the one from new-repo.
In this case specifically, I was trying to move changes between branches when the normal merge wouldn't work, so I used MQ, however I wanted the changes to remain in the working copy rather than accidentally getting pushed. It looks like one can do what I wanted with hg import --no-commit, which TortoiseHg does not currently (but should soon) provide any UI for.
So right now I'm learning Ruby on Rails, and I'm working through the book "Agile Web Development with Rails". I've also decided that I want to give Mercurial a go, because I've read up on distributed SCM's, and it seems like an ideal situation. I still, however, prefer to push my code remotely to my Linux VPS just incase my hard drive decides to take a dive.
So, my question is specific to branching in Mercurial. Right now I've got a remote repository set up and I can push changes over SSH easily (hell I even set up an Nginx FastCGI site that lets me push, too). What I'd like to do, however, is create branches for each chapter as I work on them, so I can keep a nice organized history of my progress through the book. So this is what I'm doing:
$ hg branch chapter-10
(do chapter 10 stuff)
$ hg commit -m "Chapter 10 complete"
$ hg update default
$ hg merge chapter-10
$ hg commit -m "Merging chapter 10 into default"
$ hg push
Once I execute the push statement, I get this message from Mercurial:
pushing to ssh://myserver/hg/depot
searching for changes
abort: push creates new remote branch 'chapter-10'!
(did you forget to merge? use push -f to force)
So at this point I try to do an hg merge again, and it tells me there's nothing to merge, which is obviously true because I just merged it. When I force the push with -f, everything seems fine, and even the web interface shows the appropriate branches.
To sum up, my question is simple: Am I doing this the right way? Is there a more appropriate way to do this with Mercurial (i.e. the "Mercurial way")? Honestly I just want the repository to serve as a backup. I'm a fan of the distributed SCM model, but to me it feels sorta "dirty" to force pushes. Any insight is greatly appreciated! Thanks in advance.
The push -f is the right option for your case, and there was a discussion last month to add that command when this "push creates new remote branch" warning pops up: see issue 1513.
However, issue 1974 (this month) mentions some undesirable effects (not in your case though).
See this translated article to know more about creating a second head on a remote repo.
On the more general point, you can use branch if you are writing your chapter in parallel, and you want to merge them only at certain (stable) point in time
But if your writing process is more linear, you could use only one branch, and put some tags along the way.
However, should you go back to chapter 10 and add some lines, even though you already put tags 11 and 12, that would make the history harder to read. So branches are still a good idea in this case.
I don't know about your specific problem, but from your comments it seems that you use branches where you probably wanted to use tags.
Branches are generally used when multiple people cooperate on the same project and you want to create a work separation so one person can work on a stable piece of code, while the other does something experimental that temporarily breaks functionality. Alternatively branches are used to stabilize for release, while development is going on in trunk.
Tags (or labels) are used to primarily create a marker signifying some importance to the version of code. Like for example if you want to mark a completion of chapter 10, you just tag all current versions with a 'chapter-10' tag. There is no need to branch. You can branch from a tagged version at any point in future if it would be necessary for some reason.
In this case I feel that it's totally ok to use -f for the push. It just creates new branches, not heads. Creating remote heads is another matter entirely.