Yes, you can do this using mercurial without any extensions by Concatenating Changesets. Alternately if you want to use an extension you could use: The Collapse Extension The Rebase Extension or The Histedit Extension
When “waiting for lock on repository”, delete the repository file: .hg/wlock (or it may be in .hg/store/lock) When deleting the lock file, you must make sure nothing else is accessing the repository. (If the lock is a string of zeros or blank, this is almost certainly true).
You can even add multiple entries in the [paths] section of your .hg/hgrc file. [paths] default = /repo_store/hg/project1 sandbox = /repo_store/hg/project1_experimental And then can specify its alias in the mercurial commands. default repo need not be specified but others have to be like, hg in # check incoming changes from default repo hg in default … Read more
One way would be hg rollback (deprecated as of Hg2.7, August 2013) Please use hg commit –amend instead of rollback to correct mistakes in the last commit. Roll back the last transaction in a repository. When committing or merging, Mercurial adds the changeset entry last. Mercurial keeps a transaction log of the name of each … Read more
Both existing answers suggest storing your username and password unencrypted in plain-text, which is a bit of a no-no. You should use the Keyring extension instead, as it has been specifically designed for securely saving authentication passwords. It already comes bundled with TortoiseHg, so all you have to do is activate it by writing the … Read more
With the release of Mercurial 2.2, you can use the –amend option with hg commit to update the last commit with the current working directory From the command line reference: The –amend flag can be used to amend the parent of the working directory with a new commit that contains the changes in the parent … Read more
Pushing to a network share is possible, but not recommended by the Mercurial team. See the “shared disk” part in Publishing Repositories in the Mercurial wiki: generally restricted to intranets, not generally recommended due to general issues with network filesystem reliability At my workplace, we are keeping our HG repositories on a network share (on … Read more
Update to the stiging branch and create a new branch off of it. Then close the old branch. In summary: hg update stiging hg branch staging hg commit -m”Changing stiging branch to staging.” hg update stiging hg commit –close-branch -m”This was a typo; use staging instead.” hg push –new-branch
Enable the “strip” extension and type the following: hg strip #changeset# –keep Where #changeset# is the hash for the changeset you want to remove. This will remove the said changeset including changesets that descend from it and will leave your working directory untouched. If you wish to also revert your committed code changes remove the … Read more
You can make an auth section in your .hgrc or Mercurial.ini file, like so: [auth] bb.prefix = https://bitbucket.org/repo/path bb.username = foo bb.password = foo_passwd The ‘bb’ part is an arbitrary identifier and is used to match prefix with username and password – handy for managing different username/password combos with different sites (prefix) You can also … Read more