Latest revision as of 09:01, 16 July 2018

Quick Navigation

This is the page to add your favorite Mercurial tip.

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>

If the cws is on DEV300_m60 and you pull it into a local repo that is on DEV300_m61, you will create new heads in the local repo. If you not comfortable in handling multiple heads, then dont do that!

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

then

 hg diff -r <second_parent_of_last_master_merge>

Alternatively, if you just did a pull/merge from master:

 hg export --switch-parent tip

Yet alternatively, just do

 hg outgoing <master_repository> -p --template '\n'

Obtain a list of all modules which contain changes

Sometimes it is interesting to know which modules in your CWS actually contain changes. That's quite easy to find out with

 hg out -q -M --template '{files}\n' <master_repository> | tr ' ' \\n | sed "s#/.*##" | sort | uniq

Getting some changesets from another repository

Sometimes changesets from other repositories are needed. To minimize the risk of merge conflicts later use the transplant extension:

Note 1: the transplant extension must be enabled in hgrc
Note 2: do not use the changeset revision numbers but the changeset hash values (or unique substrings)

e.g. for transplanting the two changesets 1234:fedcba98, 1245:efcd1234 and all changesets between 1256:abcd9876 and 1267:cdab7968 from another repository into the current repository run

 hg transplant -s other_repository fedc efcd abcd:cdab

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 your mercurial.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 heads

hg merge 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.

Be very careful when using it as it deletes history from your repository! Use rev hashes instead of rev numbers, as the latter are changing under strip!

Updating with multiple heads

Updating your working copy is a bit more complex when there are multiple 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.

Be careful, as this destroys any uncommited changes on the working copy. See hg up --help for details.

Containing multiple heads locally

If you (for whatever reason) have multiple heads in a local repo, pushing to outgoing will fail because it would create new heads. In this case you can specify one head and push only that one and if no new heads will be created this way, everything will work fine. Use hg heads to find the head you want to push and then use

hg push -r <changeset_id_of _selected_head>

to push this head.

You should never create multiple heads on an outgoing repo unless you really know what you are doing, because you will need to merge the heads anyway if you want your cws to be integrated someday, and thus you can do the merge before pushing just as well.

Using interwiki links to hg-wiki

You can use interwiki links to Mercurial wiki e.g. hg:OtherTools. This is may be helpful for documentation links direct to hg-wiki. Try it!

Recommended extensions

schemes extension

The schemes extension is handy to be used when developing for OOo. Sample config:

[extensions]
schemes=

[schemes]
ooo = http://hg.services.openoffice.org/
ooos = ssh://hg@hg.services.openoffice.org/

This allows you to:

hg pull ooo://cws/$CWSNAME

and:

hg push ooos://cws/$CWSNAME

diffw extension

When whitespace changes are not interesting the diffw extension is very useful (until HG's issue 127 gets resolved for good).
Sample config:

[extensions]
 hgext.extdiff=
[extdiff]
 cmd.diffw = diff
 opts.diffw = -w -r -N -p -U3

This allows you to

hg diffw -r1234 -r1235

@@ Line 4: / Line 4: @@
 = 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''.
@@ Line 9: / Line 10: @@
 hg clone -r <CWS_milestone> <local_prestine copy> <local_cws_repo>
 </pre>
-{{Documentation/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!'''}}
+{{Warn|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 ==
@@ Line 16: / Line 17: @@
 * <code>hg outgoing</code> 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: <code>hg diff -r <current_milestone_tag></code>
+If your current milestone tag is locally available:
-* If your current milestone tag is *not* locally available (might happen, see above):
+  hg diff -r <current_milestone_tag>
-**search for your last pull/merge from the master with <code>hg log -m</code>
-** <code>hg diff -r <second_parent_of_last_master_merge></code>
+If your current milestone tag is *not* locally available (might happen, see above):
-** Alternatively, if you just did a pull/merge from master: <code>hg export --switch-parent tip</code>
+* search for your last pull/merge from the master with
+  hg log -m
+* then
+  hg diff -r <second_parent_of_last_master_merge>
+Alternatively, if you just did a pull/merge from master:
+  hg export --switch-parent tip
+Yet alternatively, just do
+  hg outgoing <master_repository> -p --template '\n'
+== Obtain a list of all modules which contain changes ==
+Sometimes it is interesting to know which modules in your CWS actually contain changes. That's quite easy to find out with
+  hg out -q -M --template '{files}\n' <master_repository> | tr ' ' \\n | sed "s#/.*##" | sort | uniq
+== Getting some changesets from another repository ==
+Sometimes changesets from other repositories are needed. To minimize the risk of merge conflicts later use the transplant extension:<br>
+* Note 1: the transplant extension must be enabled in hgrc
+* Note 2: do not use the changeset revision numbers but the changeset hash values (or unique substrings)
+e.g. for transplanting the two changesets 1234:fedcba98, 1245:efcd1234 and all changesets between 1256:abcd9876 and 1267:cdab7968 from another repository into the current repository run
+  hg transplant -s other_repository fedc efcd abcd:cdab
 == Styles ==
 The default output format of some commands does not suit you? Use styles:
 *<code>hg log --style=compact</code>
-*<code>hg outgoing --style=changelog"</code>
+*<code>hg outgoing --style=changelog</code>
 * Or create your own format with the template engine:
 ** <code>hg outgoing --template '{date|shortdate} {author|person} {desc}\n' --newest-first</code>
@@ Line 52: / Line 76: @@
 ==== Merge heads ====
 * <code>hg merge</code> This is the easiest possibility.
-{{Documentation/Note|However, keep in mind, that everything you merged will end up in the master if the merged head gets integrated.}}
+{{Note|However, keep in mind, that everything you merged will end up in the master if the merged head gets integrated.}}
+{{Tip| See also [[hg:Merge| Mercurial merge documentation]]}}
 ==== 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.
+* [[hg: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!}}
+{{Warn|Be very careful when using it as it deletes history from your repository! Use rev hashes instead of rev numbers, as the latter are changing under strip!}}
-=== 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>:
+=== Updating with multiple heads ===
+Updating your working copy is a bit more complex when there are multiple heads in the repo. Quoth <code>hg up --help</code>:
 <cite>
      Update the repository's working directory to the specified
@@ Line 66: / Line 92: @@
 </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.}}
+{{Warn|Be careful, as this destroys any uncommited changes on the working copy. See <code>hg up --help</code> for details.}}
 === Containing multiple heads locally ===
-If you (for whatever reason) have multiple heads in a local repo, pushing to outgoing will fail because it would create new heads.
+If you (for whatever reason) have multiple heads in a local repo, pushing to outgoing will fail because it would create new heads. In this case you can specify one head and push only that one and if no new heads will be created this way, everything will work fine. Use <code>hg heads</code> to find the head you want to push and then use
-{{Documentation/Caution|You should never create multiple heads on an outgoing repo unless you really know what you are doing, because '''you will need to merge the heads anyway if you want your cws to be integrated someday''', and thus you can do the merge before pushing just as well.}}
+ hg push -r <changeset_id_of _selected_head>
+to push this head.
+{{Warn|You should never create multiple heads on an outgoing repo unless you really know what you are doing, because '''you will need to merge the heads anyway if you want your cws to be integrated someday''', and thus you can do the merge before pushing just as well.}}
+== Using interwiki links to hg-wiki ==
+You can use interwiki links to Mercurial wiki e.g. [[hg:OtherTools]]. This is may be helpful for documentation links direct to hg-wiki. Try it!
+= Recommended extensions =
+== schemes extension ==
+The [[hg:SchemesExtension|schemes extension]] is handy to be used when developing for OOo.
+Sample config:
+ [extensions]
+ schemes=
+ [schemes]
+ ooo = http://hg.services.openoffice.org/
+ ooos = ssh://hg@hg.services.openoffice.org/
+This allows you to:
+ hg pull ooo://cws/$CWSNAME
+and:
+ hg push ooos://cws/$CWSNAME
+== diffw extension ==
+When whitespace changes are not interesting the diffw extension is very useful
+(until HG's [http://mercurial.selenic.com/bts/issue127 issue 127] gets resolved for good).<br>
+Sample config:
+ [extensions]
+  hgext.extdiff=
+ [extdiff]
+  cmd.diffw = diff
+  opts.diffw = -w -r -N -p -U3
+This allows you to
+ hg diffw -r1234 -r1235

Difference between revisions of "Mercurial/Tips And Tricks"