Difference between revisions of "Mercurial/Tips And Tricks"
B michaelsen (Talk | contribs) (→Tips and Tricks) |
B michaelsen (Talk | contribs) |
||
Line 9: | Line 9: | ||
hg clone -r <CWS_milestone> <local_prestine copy> <local_cws_repo> | hg clone -r <CWS_milestone> <local_prestine copy> <local_cws_repo> | ||
</pre> | </pre> | ||
− | If the cws is on <code>DEV300_m60</code> and you pull it into a local repo that is on <code>DEV300_m61</code>, you will create new heads in the local repo. If you not comfortable in handling multiple heads, then '''dont do that!''' | + | {{Documemtation/Caution|If the cws is on <code>DEV300_m60</code> and you pull it into a local repo that is on <code>DEV300_m61</code>, you will create new heads in the local repo. If you not comfortable in handling multiple heads, then '''dont do that!'''}} |
== After pulling/merging == | == After pulling/merging == | ||
* <code>hg log --follow-first</code> is a convenient way to display your CWS changes at the top of the log. | * <code>hg log --follow-first</code> is a convenient way to display your CWS changes at the top of the log. | ||
Line 46: | Line 46: | ||
ssh = ssh -C | ssh = ssh -C | ||
</pre> | </pre> | ||
+ | == Handling multiple heads == | ||
+ | === Getting rid of multiple heads === | ||
+ | When you accidentally created a repo with multiple heads, these are the possibilities to get rid of them: | ||
+ | ==== Merge them ==== | ||
+ | * This is the easiest possibility. However, keep in mind, that everything you merged will end up in the master if the merged head gets integrated. | ||
+ | ==== Strip an unwanted branch ==== | ||
+ | * [http://mercurial.selenic.com/wiki/Strip hg strip] can be used to get rid of the unwanted branch. It is provided by the Mq Extension. | ||
+ | {{Documentation/Caution|Be very careful when using it as it deletes history from your repository!}} | ||
+ | === Updating with mutiple heads === | ||
+ | Updating your working copy is a bit more complex when there are mutiple heads in the repo. Quoth <code>hg up --help</code>: | ||
+ | <cite> | ||
+ | Update the repository's working directory to the specified | ||
+ | revision, or the tip '''of the current branch''' if none is specified. | ||
+ | Use null as the revision to remove the working copy (like 'hg | ||
+ | clone -U'). | ||
+ | </cite> | ||
+ | So, if you clone a repo up to <code>DEV300_m62</code> creating a working copy of its tip, and then pull a <code>DEV300_m60</code>-based cws and do a <code>hg up</code> you will not be on the tip of the cws, because Mercurial will not switch branches. If you want that, you would need a <code>hg up -C -r tip</code>. | ||
+ | {{Documentation/Caution|Be careful, as this destroys any uncommited changes on the working copy. See <code>hg up --help</code> for details.}} |
Revision as of 13:52, 27 October 2009
|
---|
Quick Navigation
|
About this template |
This is the page to add your favorite Mercurial tip.
Contents
Tips and Tricks
Preparing a local repo for a cws
- If you want to create a local repo for an existing cws, take care to clone to the milestone of the cws.
hg clone -r <CWS_milestone> <local_prestine copy> <local_cws_repo>
Template:Documemtation/Caution
After pulling/merging
-
hg log --follow-first
is a convenient way to display your CWS changes at the top of the log. -
hg log --follow-first -P <original_clone_milestone>
will show only the CWS changesets. -
hg outgoing
works as well, of course.
Combined diff which contains exactly the changes of your CWS without anything pulled from master
- If your current milestone tag is locally available:
hg diff -r <current_milestone_tag>
- If your current milestone tag is *not* locally available (might happen, see above):
- search for your last pull/merge from the master with
hg log -m
-
hg diff -r <second_parent_of_last_master_merge>
- Alternatively, if you just did a pull/merge from master:
hg export --switch-parent tip
- search for your last pull/merge from the master with
Styles
The default output format of some commands does not suit you? Use styles:
hg log --style=compact
hg outgoing --style=changelog"
- Or create your own format with the template engine:
-
hg outgoing --template '{date|shortdate} {author|person} {desc}\n' --newest-first
-
On Windows/cygwin
TortoiseHg
Depending on the cygwin version, using cygwins hg (and other tools) sometimes fails. TortoiseHg (http://bitbucket.org/tortoisehg/stable/wiki/Home) can be used as alternative.
To get rid of cygwin's hg rename /usr/bin/hg
.
You can decide which ssl support you use in the cygwin shell.
If you want to use the ssh-agent then you have to specify the following line in the [ui]
section of ~/.hgrc
:
ssh = <Windows path to cygwin>\bin\ssh.exe -C
For the graphical interface of TortoiseHg Putty's pageant is the default ssh key provider. TortoiseHg allows easy graphical access to hg repositories within the Windows Explorer.
Accessing repository over ssh
- If you want to use the ssh client of your Cygwin shell (and also ssh-agent), add the following to the
[ui]
section of yourmercurial.ini
:
ssh = ssh -C
Handling multiple heads
Getting rid of multiple heads
When you accidentally created a repo with multiple heads, these are the possibilities to get rid of them:
Merge them
- This is the easiest possibility. However, keep in mind, that everything you merged will end up in the master if the merged head gets integrated.
Strip an unwanted branch
- hg strip can be used to get rid of the unwanted branch. It is provided by the Mq Extension.
Updating with mutiple heads
Updating your working copy is a bit more complex when there are mutiple heads in the repo. Quoth hg up --help
:
Update the repository's working directory to the specified revision, or the tip of the current branch if none is specified. Use null as the revision to remove the working copy (like 'hg clone -U').
So, if you clone a repo up to DEV300_m62
creating a working copy of its tip, and then pull a DEV300_m60
-based cws and do a hg up
you will not be on the tip of the cws, because Mercurial will not switch branches. If you want that, you would need a hg up -C -r tip
.