- About Mercurial
- Setting your name
- kdiff3 for merges
- Simple Tasks
nice Mercurial "Cheatsheets" in various formats and resolutions - for a quick view for those who are new to Mercurial..
good explanation about hg and how it works http://hginit.com/
Just click the link if you want to browse the repository.
Setting your name
Edit ~/.hgrc or %USERPROFILE%\mercurial.ini and add:
[ui] username=My Name <firstname.lastname@example.org> # for hg 1.3.1 (and maybe also later versions), better NOT configure this: #merge = internal:merge
kdiff3 for merges
Add to ~/.hgrc:
[extensions] hgext.extdiff = [extdiff] cmd.kdiff3 = [merge-tools] kdiff3.args = $base $local $other -o $output
This adds a new graphical diff command hg kdiff3 (using ExtdiffExtension), and tells Mercurial to use kdiff3 for merges.
Getting the current source code
hg clone http://hg.moinmo.in/moin/2.0 moin-2.0
For every command shown in the section below, it is assumed that your current directory is moin-2.0.
Updating the repository
Before doing this, you must have a clean workdir (not containing any changes of you - so either commit your stuff or revert everything).
Read what hg tells you! If it tells you that you have to do a merge, do it - see next section.
# pull changes from the default repo into your local repo: hg pull -u # pull changes from some specific repo into your local repo: hg pull -u http://hg.moinmo.in/moin/2.0 # for merging main repo
This will merge 2 heads present in your repo into your workdir.
The merge might create merge conflicts that need to get resolved manually.
Use hg resolve -l to list resolve status (U is unresolved stuff you need to fix).
Use hg resolve -m filename to mark a file as resolved.
After merging and resolving, you must carefully review your changes (see section below) and finally commit them:
hg diff hg status hg commit -m "merged main" # use correct repo name
You MUST NOT do any non-merging related changes in your merge changeset.
There MUST NOT be any conflicts left when you commit. Conflicts are usually marked in the source code like this:
A <<<<<<< local B - my local changes ||||||| base B ======= B - changes made by others >>>>>>> other C
It is important that, if you have to move files, to use hg mv for it.
If you are just moving them in the file system, hg will just see one deleted file and one new file and you will break the history of the file.
Review your own changes
hg diff hg status
Please repeat those commands until you are completely happy with your changes (reading them one or two times, line by line, often helps to avoid errors. While reading your changes again and again, you can also think about a great commit comment.
Contribute your changes
After you have convinced yourself that you are completely happy with your changes (see section above), you can commit them to your repository:
hg commit -m 'Fixed foo' # please be more verbose! hg bundle mybundlefile http://hg.moinmo.in/moin/2.0
Then spread the file mybundlefile. ?how would one use such a "spread" bundle?
Alternatively, you can generate a patch file by writing:
hg export -o mypatchfile tip
Write access to main repository
Submit your ssh pub key to ThomasWaldmann.
Add the following line to the [paths] section of .hg/hgrc (located in the root of the repository):
default-push = ssh://email@example.com/moin/2.0
- When Thomas has installed your key file, you can write to the main repository like this:
hg commit -m "Fixed foo" hg push # server fingerprints: # 67:e3:03:85:be:03:ea:f3:ae:a1:53:66:b1:cd:26:85 (rsa) # 50:25:0a:ec:7b:bd:6e:2d:35:4f:64:24:9c:1a:e5:2d (dsa)
Importing a patch file
hg import patchfile
Revert all changes in the working directory:
hg revert --all
Roll back the last transaction in this repository, restoring the project to its state prior to the transaction.
You should rarely have to use this, see also revert. Please think and test before committing.
Posting your workdir patches on a pastebin
The most pleasant way is the hg paste extension its available at http://dev.pocoo.org/hg/hgpaste/