tortoisehg

Let's say I have the following revisions: rev 1: + Dim Foo as integer rev 2: + I like big butts, I cannot lie rev 3 - Dim Foo as integer Foo is in rev 1 & 2, and removed from three. What command can I issue that will return all changesets that Foo was added or deleted? Ideally I'd like to be able to do this from toroisehg as well You can use the grep command : hg grep --all Foo To address Lazy Badger concerns in comments. $ hg init $ echo "Dim Foo as integer" > test $ hg commit -m "1" $ echo "I like big butts, I cannot lie" > test $ hg commit -m "2" $ echo "Dim Foo as integer" > test $ hg

My colleague has committed twice on his repository on the wrong branch. What is the most effective way to take those two commits, get rid of them and then commit them correctly under the right branch? (the changes have not been pushed) We'd ideally like a way to do this from within TortoiseHG but of course, we'll use the command-line if it is the best option. The Mercurial Queues (mq) extension can help. Given a change history that looks like this: @ changeset: 3:9dc681b56325 | summary: file4 | o changeset: 2:6675b3f86aa7 | summary: file3 | | o changeset: 1:4a3209ed5b2f |/ summary: file2 | o

When I want to create a patch on my local changeset, I really I have to first commit, any I can create the patch. May I know under TortoiseHg, how I can create a patch without performing commit? alexandrul TortoiseHg 2.0.2: in workbench you can right-click on the Working Directory line and select Export / Copy patch from the contextual menu - the resulting diff will be placed in clipboard. Of course, you won't have the changeset header and the commit message at the beginning of the patch like you will get from the same operation made on a commit: # HG changeset patch # User John Doe <john@doe

Is it better to first close a branch and then merge it with the default branch(for instance) or first merge it and then close it? In TortoiseHg for instance, in the first case, you'll see a line from a close node to the default branch. In the second case you'll see a line from the last commit to the default branch and an extra line from the last commit to a close node. I hope I'm clear. Maybe it's a matter of taste... There is no real difference between the two methods when talking about named branches, at least in any recent version of Mercurial. Things were different pre-1.5(?), but purely

When committing changes to Mercurial, it can auto-detect move/copy/renames by using the command hg addremove -similarity 100 The number after similarity indicates how similar two files need to be from 0-100% for mercurial to decide its a move, copy or rename instead of just a new file. This is a great feature. Can TortoiseHg do this? Yes it can. If you take a look at the TortoiseHg manual you'll find section 4.12 entitled "Rename Guessing". To quote: Select one or more Unrevisioned Files Slide the similarity bar ( Minimum Similarity Percentage ) to the percentage match you want Press either