As the repository of hg itself, some changesets are marked with 'stable'. I am wondering how to add the 'stable' mark to changesets. I had googled but it doesn't help. I tried 'hg help tag' but still can not figure out how to do it. Do I miss something very basic?
Thanks in advance.
I believe they are not "marked" as stable.
Those commits are part of the branch 'stable' history.
See the graph:
This is named branch, not tag. hg help branch, or better read Mercurial Book: http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html
Related
In Mercurial, I'm wanting to build a changelog of all commit messages for revisions my stable branch. Currently, I'm using:
hg log -r <oldid>::<newid>
where is the revision id of the changeset from the last time we pushed out code, and is stable's tip. This works great for code changes that are only on the stable branch, but if I'm merging another branch (such as a new major version which had its own development branch), all those commit messages are omitted! Instead I only get the 1 commit from where it merged into stable. I would like some way (preferably w/ hg log) to see these as well.
I do NOT want to get any "unpublished" commits in this list - that is, commits on any branches which haven't been merged into stable.
Here is an example of what I'm looking for:
In this example, the last pushed revision is 540. Because of this, I don't want anything at 540 or below. There are several branches out into default and back in to stable, and I want all of these (539, 541-557 in green). However, there are some changes NOT merged back into stable (558-563) which I wish to omit. Pay special attention to Revision 539; it was NOT merged into stable when 540 was published, and therefore was not included. But now it has since been merged into stable, so I would like to include it!
Any advice you guys have would be greatly appreciated. Thanks!
Not 100% sure if this will work:
hg log -r '::stable - ::540'
I'm uncertain about it because I would have thought the command you provided would mostly be correct, except for changeset 539. You're not passing -b stable to hg log by mistake, are you?
Have a look at revsets. Kevin posted the short form of what you want - here's the long form:
hg log -r "ancestors('stable') and not ancestors(540)"
Revsets are incredibly powerful, and you can just enter them into the filter bar of TortoiseHg.
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.
I had 3 change sets that I wanted to rebase on top of the latest revisions. Unfortunately, I selected only one of them to be rebased and so this did a merge. Is there any way I can either undo the rebase or change it so the other two change sets get rebased as well?
Assuming you haven't pushed it to another repo for others to grab, then you can put those changesets anywhere on the graph you want. You can move changesets with hg rebase and prune changsets and their descendents with hg strip.
Both strip and rebase save "undo" information as bundle files in your .hg/strip-backup/
Note that neither strip nor rebase are enabled by default with mercurial. You need to enable them in the .hgrc file.
If it's the very last thing you did you can do a 'hg rollback' which is a one-level undo. If, however, you've done anything since that alters the repository state (push, pull, commit, etc.) then rollback won't help you.
If it's any consolation, merging is generally preferable to rebasing and a mercurial history with a lot of merges shows someone who is using mercurial to its fullest. :)
Recently, I've started experimenting with Mercurial, due to the fact that it always attracted it because of its simplicity and "just works" principle. Or at least, that's how others always described it.
They also usually described it as "practically the same as git with just a few minor changes you won't notice" - only for me to discover it isn't quite so.
I'm having problem with Hg branches. Pardon me if this is an overly simple question, but in git one has a working directory and a repo (.git). In the repo one has revisions, and branches, and can jump from one to another.
I'm having trouble finding a similar model in Hg. As far as I can see, for Hg to have a "branch" one needs to clone a repo to another directory? Is there a way Hg could work just like git does - i.e. one working dir., and one repo, in which you can do things as regard to branching and revs?
Mercurial supports a very rich set of ways to branch. See http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
In brief, you can create a named branch by running
hg branch NewBranch
and switch to that branch using
hg up NewBranch
or switch back to trunk using
hg up default
In Mercurial, if you go to any particular revision, you can always edit your working copy and commit, thereby making another "head." Merging works on head revisions by default. You can use hg head to see what heads are in your repository. This seems to be the most "idiomatic" way I have found branching to work in Mercurial.
Take a look at section about branches in my answer to "Git and Mercurial - Compare and Contrast" here on StackOverflow.
The information about various options available for branching in Mercurial (anonymous heads, not-propagated (I think yet still) bookmarks, and global (world-wide) commit labels aka named branches) was taken from http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/, and expanded using feedback on #mercurial IRC channel on FreeNode.
Note: I asked this yesterday over at kiln.stackexchange.com, but haven't gotten an answer, and it's holding up my work. So I figured I'd give it a shot here.
My main mercurial repository has a bunch of subrepositories in it. During initial setup, I made a mistake in my .hgsub. Namely, I pointed two subrepositories to the same directory.
What I should have had:
sites/1=sites/1
sites/2=sites/2
sites/3=sites/3
What I actually had:
sites/1=sites/1
sites/2=sites/2
sites/2=sites/3
Stupid copy/paste error. I committed the incorrect .hgsub, not realizing my error. A few revisions later, while adding a some new subrespositories to .hgsub, I noticed the mistake and fixed it inside .hgsub. I committed and kept rolling along. I've committed a reasonable amount of work that I'd prefer not to redo since I 'fixed' the mistake in .hgsub.
Now we come to the actual problem: I've made some changes inside the subrepository sites/3, and when I try to commit the main repository, I get the following error:
abort: unknown revision 'LongGUIDLookingString'
I found this discussion, which seems to address the same problem I'm having, but I can't quite work out how bos fixed it. What do I need to do in order to fix this?
Relevant section of .hgsubstate:
7d1e430ac5f12e00cb5bebcdf693e72db2c45732 sites/1
6eea936a5b7cfff6169f59d0dc1c8c4eb5f8412d sites/2
e2b83b301997de8add1b659d82a7ab8201bda653 sites/3
I'd guess the .hgsubstate file now contains a hashid (which is what your LongGUIDLookingString is) from repo3 in the repo2 entry.
Try editing .hgsubstate to point to a correct/present hashid for each repo.
If that doesn't work, please paste i your .hgsubstate file so we can see how it can be tweaked.
For those who struggle committing changes to .hgsubstate, it appears that:
hg commit -i is not working while
hg commit -m does.