1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
|
---
category: tool
tool: Mercurial
contributors:
- ["Will L. Fife", "http://github.com/sarlalian"]
filename: LearnMercurial.txt
---
Mercurial is a free, distributed source control management tool. It offers
you the power to efficiently handle projects of any size while using an
intuitive interface. It is easy to use and hard to break, making it ideal for
anyone working with versioned files.
## Versioning Concepts
### What is version control?
Version control is a system that keeps track fo changes to a set of file(s)
and/or directorie(s) over time.
### Why use Mercurial?
* Distributed Architecture - Traditionally version control systems such as CVS
and Subversion are a client server architecture with a central server to
store the revsion history of a project. Mercurial however is a truly
distributed architecture, giving each devloper a full local copy of the
entire development history. It works independently of a central server.
* Fast - Traditionally version control systems such as CVS and Subversion are a
client server architecture with a central server to store the revsion history
of a project. Mercurial however is a truly distributed architecture, giving
each devloper a full local copy of the entire development history. It works
independently of a central server.
* Platform Independent - Mercurial was written to be highly platform
independent. Much of Mercurial is written in Python, with small performance
critical parts written in portable C. Binary releases are available for all
major platforms.
* Extensible - The functionality of Mercurial can be increased with extensions,
either by activating the official ones which are shipped with Mercurial or
downloading some [from the wiki](https://www.mercurial-scm.org/wiki/UsingExtensions) or by [writing your own](https://www.mercurial-scm.org/wiki/WritingExtensions). Extensions are written in
Python and can change the workings of the basic commands, add new commands and
access all the core functions of Mercurial.
* Easy to use - The Mercurial command set is consistent with what subversion
users would expect, so they are likely to feel right at home. Most dangerous
actions are part of extensions that need to be enabled to be used.
* Open Source - Mercurial is free software licensed under the terms of the [GNU
General Public License Version 2](http://www.gnu.org/licenses/gpl-2.0.txt) or
any later version.
## Terminology
| Term | Definition |
| ------------- | ---------------------------------- |
| Repository | A repository is a collection of revisions |
| hgrc | A configuration file which stores the defaults for a repository. |
| revision | A committed changeset: has a REV number |
| changeset | Set of changes saved as diffs |
| diff | Changes between file(s) |
| tag | A named named revision |
| parent(s) | Immediate ancestor(s) of a revison |
| branch | A child of a revision |
| head | A head is a changeset with no child changesets |
| merge | The process of merging two HEADS |
| tip | The latest revision in any branch |
| patch | All of the diffs between two revisions |
| bundle | Patch with permisĀsions and rename support |
## Commands
### init
Create a new repository in the given directory, the settings and stored
information are in a directory named `.hg`.
```bash
$ hg init
```
### help
Will give you access to a very detailed description of each command.
```bash
# Quickly check what commands are available
$ hg help
# Get help on a specific command
# hg help <command>
$ hg help add
$ hg help commit
$ hg help init
```
### status
Show the differences between what is on disk and what is committed to the current
branch or tag.
```bash
# Will display the status of files
$ hg status
# Get help on the status subcommand
$ hg help status
```
### add
Will add the specified files to the repository on the next commit.
```bash
# Add a file in the current directory
$ hg add filename.rb
# Add a file in a sub directory
$ hg add foo/bar/filename.rb
# Add files by pattern
$ hg add *.rb
```
### branch
Set or show the current branch name.
*Branch names are permanent and global. Use 'hg bookmark' to create a
light-weight bookmark instead. See 'hg help glossary' for more information
about named branches and bookmarks.*
```bash
# With no argument it shows the current branch name
$ hg branch
# With a name argument it will change the current branch.
$ hg branch new_branch
marked working directory as branch new_branch
(branches are permanent and global, did you want a bookmark?)
```
### tag
Add one or more tags for the current or given revision.
Tags are used to name particular revisions of the repository and are very
useful to compare different revisions, to go back to significant earlier
versions or to mark branch points as releases, etc. Changing an existing tag
is normally disallowed; use -f/--force to override.
```bash
# List tags
$ hg tags
tip 2:efc8222cd1fb
v1.0 0:37e9b57123b3
# Create a new tag on the current revision
$ hg tag v1.1
# Create a tag on a specific revision
$ hg tag -r efc8222cd1fb v1.1.1
```
### clone
Create a copy of an existing repository in a new directory.
If no destination directory name is specified, it defaults to the basename of
the source.
```bash
# Clone a remote repo to a local directory
$ hg clone https://some-mercurial-server.example.com/reponame
# Clone a local repo to a remote server
$ hg clone . ssh://username@some-mercurial-server.example.com/newrepo
# Clone a local repo to a local repo
$ hg clone . /tmp/some_backup_dir
```
### commit / ci
Commit changes to the given files into the repository.
```bash
# Commit with a message
$ hg commit -m 'This is a commit message'
# Commit all added / removed files in the currrent tree
$ hg commit -A 'Adding and removing all existing files in the tree'
# amend the parent of the working directory with a new commit that contains the
# changes in the parent in addition to those currently reported by 'hg status',
$ hg commit --amend -m "Correct message"
```
### diff
Show differences between revisions for the specified files using the unified
diff format.
```bash
# Show the diff between the current directory and a previous revision
$ hg diff -r 10
# Show the diff between two previous revisions
$ hg diff -r 30 -r 20
```
### grep
Search revision history for a pattern in specified files.
```bash
# Search files for a specific phrase
$ hg grep "TODO:"
```
### log / history
Show revision history of entire repository or files. If no revision range is
specified, the default is "tip:0" unless --follow is set, in which case the
working directory parent is used as the starting revision.
```bash
# Show the history of the entire repository
$ hg log
# Show the history of a single file
$ hg log myfile.rb
# Show the revision changes as an ASCII art DAG with the most recent changeset
# at the top.
$ hg log -G
```
### merge
Merge another revision into working directory.
```bash
# Merge changesets to local repository
$ hg merge
# Merge from a named branch or revision into the current local branch
$ hg merge branchname_or_revision
# After successful merge, commit the changes
hg commit
```
### move / mv / rename
Rename files; equivalent of copy + remove. Mark dest as copies of sources;
mark sources for deletion. If dest is a directory, copies are put in that
directory. If dest is a file, there can only be one source.
```bash
# Rename a single file
$ hg mv foo.txt bar.txt
# Rename a directory
$ hg mv some_directory new_directory
```
### pull
Pull changes from a remote repository to a local one.
```bash
# List remote paths
$ hg paths
remote1 = http://path/to/remote1
remote2 = http://path/to/remote2
# Pull from remote 1
$ hg pull remote1
# Pull from remote 2
$ hg pull remote2
```
### push
Push changesets from the local repository to the specified destination.
```bash
# List remote paths
$ hg paths
remote1 = http://path/to/remote1
remote2 = http://path/to/remote2
# Pull from remote 1
$ hg push remote1
# Pull from remote 2
$ hg push remote2
```
### rebase
Move changeset (and descendants) to a different branch.
Rebase uses repeated merging to graft changesets from one part of history
(the source) onto another (the destination). This can be useful for
linearizing *local* changes relative to a master development tree.
* Draft the commits back to the source revision.
* -s is the source, ie. what you are rebasing.
* -d is the destination, which is where you are sending it.
```bash
# Put the commits into draft status
# This will draft all subsequent commits on the relevant branch
$ hg phase --draft --force -r 1206
# Rebase from from revision 102 over revision 208
$ hg rebase -s 102 -d 208
```
### revert
Restore files to their checkout state. With no revision specified, revert the
specified files or directories to the contents they had in the parent of the
working directory. This restores the contents of files to an unmodified state
and unschedules adds, removes, copies, and renames. If the working directory
has two parents, you must explicitly specify a revision.
```bash
# Reset a specific file to its checked out state
$ hg revert oops_i_did_it_again.txt
# Revert a specific file to its checked out state without leaving a .orig file
# around
$ hg revert -C oops_i_did_it_again.txt
# Revert all changes
$ hg revert -a
```
### rm / remove
Remove the specified files on the next commit.
```bash
# Remove a spcific file
$ hg remove go_away.txt
# Remove a group of files by pattern
$ hg remove *.txt
```
## Further information
* [Learning Mercurial in Workflows](https://www.mercurial-scm.org/guide)
* [Mercurial Quick Start](https://www.mercurial-scm.org/wiki/QuickStart)
* [Mercurial: The Definitive Guide by Bryan O'Sullivan](http://hgbook.red-bean.com/)
|