hgbook
diff en/ch04-daily.xml @ 650:7e7c47481e4f
Oops, this is the real merge for my hg's oddity
author | Dongsheng Song <dongsheng.song@gmail.com> |
---|---|
date | Fri Mar 20 16:43:35 2009 +0800 (2009-03-20) |
parents | en/ch05-daily.xml@cfdb601a3c8b |
children | 1c13ed2130a7 |
line diff
1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/en/ch04-daily.xml Fri Mar 20 16:43:35 2009 +0800 1.3 @@ -0,0 +1,544 @@ 1.4 +<!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> 1.5 + 1.6 +<chapter id="chap.daily"> 1.7 + <?dbhtml filename="mercurial-in-daily-use.html"?> 1.8 + <title>Mercurial in daily use</title> 1.9 + 1.10 + <sect1> 1.11 + <title>Telling Mercurial which files to track</title> 1.12 + 1.13 + <para id="x_1a3">Mercurial does not work with files in your repository unless 1.14 + you tell it to manage them. The <command role="hg-cmd">hg 1.15 + status</command> command will tell you which files Mercurial 1.16 + doesn't know about; it uses a 1.17 + <quote><literal>?</literal></quote> to display such 1.18 + files.</para> 1.19 + 1.20 + <para id="x_1a4">To tell Mercurial to track a file, use the <command 1.21 + role="hg-cmd">hg add</command> command. Once you have added a 1.22 + file, the entry in the output of <command role="hg-cmd">hg 1.23 + status</command> for that file changes from 1.24 + <quote><literal>?</literal></quote> to 1.25 + <quote><literal>A</literal></quote>.</para> 1.26 + 1.27 + &interaction.daily.files.add; 1.28 + 1.29 + <para id="x_1a5">After you run a <command role="hg-cmd">hg commit</command>, 1.30 + the files that you added before the commit will no longer be 1.31 + listed in the output of <command role="hg-cmd">hg 1.32 + status</command>. The reason for this is that <command 1.33 + role="hg-cmd">hg status</command> only tells you about 1.34 + <quote>interesting</quote> files&emdash;those that you have 1.35 + modified or told Mercurial to do something with&emdash;by 1.36 + default. If you have a repository that contains thousands of 1.37 + files, you will rarely want to know about files that Mercurial 1.38 + is tracking, but that have not changed. (You can still get this 1.39 + information; we'll return to this later.)</para> 1.40 + 1.41 + <para id="x_1a6">Once you add a file, Mercurial doesn't do anything with it 1.42 + immediately. Instead, it will take a snapshot of the file's 1.43 + state the next time you perform a commit. It will then continue 1.44 + to track the changes you make to the file every time you commit, 1.45 + until you remove the file.</para> 1.46 + 1.47 + <sect2> 1.48 + <title>Explicit versus implicit file naming</title> 1.49 + 1.50 + <para id="x_1a7">A useful behaviour that Mercurial has is that if you pass 1.51 + the name of a directory to a command, every Mercurial command 1.52 + will treat this as <quote>I want to operate on every file in 1.53 + this directory and its subdirectories</quote>.</para> 1.54 + 1.55 + &interaction.daily.files.add-dir; 1.56 + 1.57 + <para id="x_1a8">Notice in this example that Mercurial printed the names of 1.58 + the files it added, whereas it didn't do so when we added the 1.59 + file named <filename>a</filename> in the earlier 1.60 + example.</para> 1.61 + 1.62 + <para id="x_1a9">What's going on is that in the former case, we explicitly 1.63 + named the file to add on the command line, so the assumption 1.64 + that Mercurial makes in such cases is that you know what you 1.65 + were doing, and it doesn't print any output.</para> 1.66 + 1.67 + <para id="x_1aa">However, when we <emphasis>imply</emphasis> the names of 1.68 + files by giving the name of a directory, Mercurial takes the 1.69 + extra step of printing the name of each file that it does 1.70 + something with. This makes it more clear what is happening, 1.71 + and reduces the likelihood of a silent and nasty surprise. 1.72 + This behaviour is common to most Mercurial commands.</para> 1.73 + 1.74 + </sect2> 1.75 + <sect2> 1.76 + <title>Aside: Mercurial tracks files, not directories</title> 1.77 + 1.78 + <para id="x_1ab">Mercurial does not track directory information. Instead, 1.79 + it tracks the path to a file. Before creating a file, it 1.80 + first creates any missing directory components of the path. 1.81 + After it deletes a file, it then deletes any empty directories 1.82 + that were in the deleted file's path. This sounds like a 1.83 + trivial distinction, but it has one minor practical 1.84 + consequence: it is not possible to represent a completely 1.85 + empty directory in Mercurial.</para> 1.86 + 1.87 + <para id="x_1ac">Empty directories are rarely useful, and there are 1.88 + unintrusive workarounds that you can use to achieve an 1.89 + appropriate effect. The developers of Mercurial thus felt 1.90 + that the complexity that would be required to manage empty 1.91 + directories was not worth the limited benefit this feature 1.92 + would bring.</para> 1.93 + 1.94 + <para id="x_1ad">If you need an empty directory in your repository, there 1.95 + are a few ways to achieve this. One is to create a directory, 1.96 + then <command role="hg-cmd">hg add</command> a 1.97 + <quote>hidden</quote> file to that directory. On Unix-like 1.98 + systems, any file name that begins with a period 1.99 + (<quote><literal>.</literal></quote>) is treated as hidden by 1.100 + most commands and GUI tools. This approach is illustrated 1.101 + below.</para> 1.102 + 1.103 +&interaction.daily.files.hidden; 1.104 + 1.105 + <para id="x_1ae">Another way to tackle a need for an empty directory is to 1.106 + simply create one in your automated build scripts before they 1.107 + will need it.</para> 1.108 + 1.109 + </sect2> 1.110 + </sect1> 1.111 + <sect1> 1.112 + <title>How to stop tracking a file</title> 1.113 + 1.114 + <para id="x_1af">Once you decide that a file no longer belongs in your 1.115 + repository, use the <command role="hg-cmd">hg remove</command> 1.116 + command; this deletes the file, and tells Mercurial to stop 1.117 + tracking it. A removed file is represented in the output of 1.118 + <command role="hg-cmd">hg status</command> with a 1.119 + <quote><literal>R</literal></quote>.</para> 1.120 + 1.121 + &interaction.daily.files.remove; 1.122 + 1.123 + <para id="x_1b0">After you <command role="hg-cmd">hg remove</command> a file, 1.124 + Mercurial will no longer track changes to that file, even if you 1.125 + recreate a file with the same name in your working directory. 1.126 + If you do recreate a file with the same name and want Mercurial 1.127 + to track the new file, simply <command role="hg-cmd">hg 1.128 + add</command> it. Mercurial will know that the newly added 1.129 + file is not related to the old file of the same name.</para> 1.130 + 1.131 + <sect2> 1.132 + <title>Removing a file does not affect its history</title> 1.133 + 1.134 + <para id="x_1b1">It is important to understand that removing a file has 1.135 + only two effects.</para> 1.136 + <itemizedlist> 1.137 + <listitem><para id="x_1b2">It removes the current version of the file 1.138 + from the working directory.</para> 1.139 + </listitem> 1.140 + <listitem><para id="x_1b3">It stops Mercurial from tracking changes to 1.141 + the file, from the time of the next commit.</para> 1.142 + </listitem></itemizedlist> 1.143 + <para id="x_1b4">Removing a file <emphasis>does not</emphasis> in any way 1.144 + alter the <emphasis>history</emphasis> of the file.</para> 1.145 + 1.146 + <para id="x_1b5">If you update the working directory to a changeset in 1.147 + which a file that you have removed was still tracked, it will 1.148 + reappear in the working directory, with the contents it had 1.149 + when you committed that changeset. If you then update the 1.150 + working directory to a later changeset, in which the file had 1.151 + been removed, Mercurial will once again remove the file from 1.152 + the working directory.</para> 1.153 + 1.154 + </sect2> 1.155 + <sect2> 1.156 + <title>Missing files</title> 1.157 + 1.158 + <para id="x_1b6">Mercurial considers a file that you have deleted, but not 1.159 + used <command role="hg-cmd">hg remove</command> to delete, to 1.160 + be <emphasis>missing</emphasis>. A missing file is 1.161 + represented with <quote><literal>!</literal></quote> in the 1.162 + output of <command role="hg-cmd">hg status</command>. 1.163 + Mercurial commands will not generally do anything with missing 1.164 + files.</para> 1.165 + 1.166 + &interaction.daily.files.missing; 1.167 + 1.168 + <para id="x_1b7">If your repository contains a file that <command 1.169 + role="hg-cmd">hg status</command> reports as missing, and 1.170 + you want the file to stay gone, you can run <command 1.171 + role="hg-cmd">hg remove <option 1.172 + role="hg-opt-remove">--after</option></command> at any 1.173 + time later on, to tell Mercurial that you really did mean to 1.174 + remove the file.</para> 1.175 + 1.176 + &interaction.daily.files.remove-after; 1.177 + 1.178 + <para id="x_1b8">On the other hand, if you deleted the missing file by 1.179 + accident, give <command role="hg-cmd">hg revert</command> the 1.180 + name of the file to recover. It will reappear, in unmodified 1.181 + form.</para> 1.182 + 1.183 +&interaction.daily.files.recover-missing; 1.184 + 1.185 + </sect2> 1.186 + <sect2> 1.187 + <title>Aside: why tell Mercurial explicitly to remove a 1.188 + file?</title> 1.189 + 1.190 + <para id="x_1b9">You might wonder why Mercurial requires you to explicitly 1.191 + tell it that you are deleting a file. Early during the 1.192 + development of Mercurial, it let you delete a file however you 1.193 + pleased; Mercurial would notice the absence of the file 1.194 + automatically when you next ran a <command role="hg-cmd">hg 1.195 + commit</command>, and stop tracking the file. In practice, 1.196 + this made it too easy to accidentally remove a file without 1.197 + noticing.</para> 1.198 + 1.199 + </sect2> 1.200 + <sect2> 1.201 + <title>Useful shorthand&emdash;adding and removing files in one 1.202 + step</title> 1.203 + 1.204 + <para id="x_1ba">Mercurial offers a combination command, <command 1.205 + role="hg-cmd">hg addremove</command>, that adds untracked 1.206 + files and marks missing files as removed.</para> 1.207 + 1.208 + &interaction.daily.files.addremove; 1.209 + 1.210 + <para id="x_1bb">The <command role="hg-cmd">hg commit</command> command 1.211 + also provides a <option role="hg-opt-commit">-A</option> 1.212 + option that performs this same add-and-remove, immediately 1.213 + followed by a commit.</para> 1.214 + 1.215 + &interaction.daily.files.commit-addremove; 1.216 + 1.217 + </sect2> 1.218 + </sect1> 1.219 + <sect1> 1.220 + <title>Copying files</title> 1.221 + 1.222 + <para id="x_1bc">Mercurial provides a <command role="hg-cmd">hg 1.223 + copy</command> command that lets you make a new copy of a 1.224 + file. When you copy a file using this command, Mercurial makes 1.225 + a record of the fact that the new file is a copy of the original 1.226 + file. It treats these copied files specially when you merge 1.227 + your work with someone else's.</para> 1.228 + 1.229 + <sect2> 1.230 + <title>The results of copying during a merge</title> 1.231 + 1.232 + <para id="x_1bd">What happens during a merge is that changes 1.233 + <quote>follow</quote> a copy. To best illustrate what this 1.234 + means, let's create an example. We'll start with the usual 1.235 + tiny repository that contains a single file.</para> 1.236 + 1.237 + &interaction.daily.copy.init; 1.238 + 1.239 + <para id="x_1be">We need to do some work in 1.240 + parallel, so that we'll have something to merge. So let's 1.241 + clone our repository.</para> 1.242 + 1.243 + &interaction.daily.copy.clone; 1.244 + 1.245 + <para id="x_1bf">Back in our initial repository, let's use the <command 1.246 + role="hg-cmd">hg copy</command> command to make a copy of 1.247 + the first file we created.</para> 1.248 + 1.249 + &interaction.daily.copy.copy; 1.250 + 1.251 + <para id="x_1c0">If we look at the output of the <command role="hg-cmd">hg 1.252 + status</command> command afterwards, the copied file looks 1.253 + just like a normal added file.</para> 1.254 + 1.255 + &interaction.daily.copy.status; 1.256 + 1.257 + <para id="x_1c1">But if we pass the <option 1.258 + role="hg-opt-status">-C</option> option to <command 1.259 + role="hg-cmd">hg status</command>, it prints another line of 1.260 + output: this is the file that our newly-added file was copied 1.261 + <emphasis>from</emphasis>.</para> 1.262 + 1.263 + &interaction.daily.copy.status-copy; 1.264 + 1.265 + <para id="x_1c2">Now, back in the repository we cloned, let's make a change 1.266 + in parallel. We'll add a line of content to the original file 1.267 + that we created.</para> 1.268 + 1.269 + &interaction.daily.copy.other; 1.270 + 1.271 + <para id="x_1c3">Now we have a modified <filename>file</filename> in this 1.272 + repository. When we pull the changes from the first 1.273 + repository, and merge the two heads, Mercurial will propagate 1.274 + the changes that we made locally to <filename>file</filename> 1.275 + into its copy, <filename>new-file</filename>.</para> 1.276 + 1.277 + &interaction.daily.copy.merge; 1.278 + 1.279 + </sect2> 1.280 + <sect2 id="sec.daily.why-copy"> 1.281 + <title>Why should changes follow copies?</title> 1.282 + 1.283 + <para id="x_1c4">This behaviour, of changes to a file propagating out to 1.284 + copies of the file, might seem esoteric, but in most cases 1.285 + it's highly desirable.</para> 1.286 + 1.287 + <para id="x_1c5">First of all, remember that this propagation 1.288 + <emphasis>only</emphasis> happens when you merge. So if you 1.289 + <command role="hg-cmd">hg copy</command> a file, and 1.290 + subsequently modify the original file during the normal course 1.291 + of your work, nothing will happen.</para> 1.292 + 1.293 + <para id="x_1c6">The second thing to know is that modifications will only 1.294 + propagate across a copy as long as the repository that you're 1.295 + pulling changes from <emphasis>doesn't know</emphasis> about 1.296 + the copy.</para> 1.297 + 1.298 + <para id="x_1c7">The reason that Mercurial does this is as follows. Let's 1.299 + say I make an important bug fix in a source file, and commit 1.300 + my changes. Meanwhile, you've decided to <command 1.301 + role="hg-cmd">hg copy</command> the file in your repository, 1.302 + without knowing about the bug or having seen the fix, and you 1.303 + have started hacking on your copy of the file.</para> 1.304 + 1.305 + <para id="x_1c8">If you pulled and merged my changes, and Mercurial 1.306 + <emphasis>didn't</emphasis> propagate changes across copies, 1.307 + your source file would now contain the bug, and unless you 1.308 + remembered to propagate the bug fix by hand, the bug would 1.309 + <emphasis>remain</emphasis> in your copy of the file.</para> 1.310 + 1.311 + <para id="x_1c9">By automatically propagating the change that fixed the bug 1.312 + from the original file to the copy, Mercurial prevents this 1.313 + class of problem. To my knowledge, Mercurial is the 1.314 + <emphasis>only</emphasis> revision control system that 1.315 + propagates changes across copies like this.</para> 1.316 + 1.317 + <para id="x_1ca">Once your change history has a record that the copy and 1.318 + subsequent merge occurred, there's usually no further need to 1.319 + propagate changes from the original file to the copied file, 1.320 + and that's why Mercurial only propagates changes across copies 1.321 + until this point, and no further.</para> 1.322 + 1.323 + </sect2> 1.324 + <sect2> 1.325 + <title>How to make changes <emphasis>not</emphasis> follow a 1.326 + copy</title> 1.327 + 1.328 + <para id="x_1cb">If, for some reason, you decide that this business of 1.329 + automatically propagating changes across copies is not for 1.330 + you, simply use your system's normal file copy command (on 1.331 + Unix-like systems, that's <command>cp</command>) to make a 1.332 + copy of a file, then <command role="hg-cmd">hg add</command> 1.333 + the new copy by hand. Before you do so, though, please do 1.334 + reread section <xref linkend="sec.daily.why-copy"/>, and make 1.335 + an informed 1.336 + decision that this behaviour is not appropriate to your 1.337 + specific case.</para> 1.338 + 1.339 + </sect2> 1.340 + <sect2> 1.341 + <title>Behaviour of the <command role="hg-cmd">hg copy</command> 1.342 + command</title> 1.343 + 1.344 + <para id="x_1cc">When you use the <command role="hg-cmd">hg copy</command> 1.345 + command, Mercurial makes a copy of each source file as it 1.346 + currently stands in the working directory. This means that if 1.347 + you make some modifications to a file, then <command 1.348 + role="hg-cmd">hg copy</command> it without first having 1.349 + committed those changes, the new copy will also contain the 1.350 + modifications you have made up until that point. (I find this 1.351 + behaviour a little counterintuitive, which is why I mention it 1.352 + here.)</para> 1.353 + 1.354 + <para id="x_1cd">The <command role="hg-cmd">hg copy</command> command acts 1.355 + similarly to the Unix <command>cp</command> command (you can 1.356 + use the <command role="hg-cmd">hg cp</command> alias if you 1.357 + prefer). The last argument is the 1.358 + <emphasis>destination</emphasis>, and all prior arguments are 1.359 + <emphasis>sources</emphasis>. If you pass it a single file as 1.360 + the source, and the destination does not exist, it creates a 1.361 + new file with that name.</para> 1.362 + 1.363 + &interaction.daily.copy.simple; 1.364 + 1.365 + <para id="x_1ce">If the destination is a directory, Mercurial copies its 1.366 + sources into that directory.</para> 1.367 + 1.368 + &interaction.daily.copy.dir-dest; 1.369 + 1.370 + <para id="x_1cf">Copying a directory is 1.371 + recursive, and preserves the directory structure of the 1.372 + source.</para> 1.373 + 1.374 + &interaction.daily.copy.dir-src; 1.375 + 1.376 + <para id="x_1d0">If the source and destination are both directories, the 1.377 + source tree is recreated in the destination directory.</para> 1.378 + 1.379 + &interaction.daily.copy.dir-src-dest; 1.380 + 1.381 + <para id="x_1d1">As with the <command role="hg-cmd">hg rename</command> 1.382 + command, if you copy a file manually and then want Mercurial 1.383 + to know that you've copied the file, simply use the <option 1.384 + role="hg-opt-copy">--after</option> option to <command 1.385 + role="hg-cmd">hg copy</command>.</para> 1.386 + 1.387 + &interaction.daily.copy.after; 1.388 + 1.389 + </sect2> 1.390 + </sect1> 1.391 + <sect1> 1.392 + <title>Renaming files</title> 1.393 + 1.394 + <para id="x_1d2">It's rather more common to need to rename a file than to 1.395 + make a copy of it. The reason I discussed the <command 1.396 + role="hg-cmd">hg copy</command> command before talking about 1.397 + renaming files is that Mercurial treats a rename in essentially 1.398 + the same way as a copy. Therefore, knowing what Mercurial does 1.399 + when you copy a file tells you what to expect when you rename a 1.400 + file.</para> 1.401 + 1.402 + <para id="x_1d3">When you use the <command role="hg-cmd">hg rename</command> 1.403 + command, Mercurial makes a copy of each source file, then 1.404 + deletes it and marks the file as removed.</para> 1.405 + 1.406 + &interaction.daily.rename.rename; 1.407 + 1.408 + <para id="x_1d4">The <command role="hg-cmd">hg status</command> command shows 1.409 + the newly copied file as added, and the copied-from file as 1.410 + removed.</para> 1.411 + 1.412 + &interaction.daily.rename.status; 1.413 + 1.414 + <para id="x_1d5">As with the results of a <command role="hg-cmd">hg 1.415 + copy</command>, we must use the <option 1.416 + role="hg-opt-status">-C</option> option to <command 1.417 + role="hg-cmd">hg status</command> to see that the added file 1.418 + is really being tracked by Mercurial as a copy of the original, 1.419 + now removed, file.</para> 1.420 + 1.421 + &interaction.daily.rename.status-copy; 1.422 + 1.423 + <para id="x_1d6">As with <command role="hg-cmd">hg remove</command> and 1.424 + <command role="hg-cmd">hg copy</command>, you can tell Mercurial 1.425 + about a rename after the fact using the <option 1.426 + role="hg-opt-rename">--after</option> option. In most other 1.427 + respects, the behaviour of the <command role="hg-cmd">hg 1.428 + rename</command> command, and the options it accepts, are 1.429 + similar to the <command role="hg-cmd">hg copy</command> 1.430 + command.</para> 1.431 + 1.432 + <sect2> 1.433 + <title>Renaming files and merging changes</title> 1.434 + 1.435 + <para id="x_1d7">Since Mercurial's rename is implemented as 1.436 + copy-and-remove, the same propagation of changes happens when 1.437 + you merge after a rename as after a copy.</para> 1.438 + 1.439 + <para id="x_1d8">If I modify a file, and you rename it to a new name, and 1.440 + then we merge our respective changes, my modifications to the 1.441 + file under its original name will be propagated into the file 1.442 + under its new name. (This is something you might expect to 1.443 + <quote>simply work,</quote> but not all revision control 1.444 + systems actually do this.)</para> 1.445 + 1.446 + <para id="x_1d9">Whereas having changes follow a copy is a feature where 1.447 + you can perhaps nod and say <quote>yes, that might be 1.448 + useful,</quote> it should be clear that having them follow a 1.449 + rename is definitely important. Without this facility, it 1.450 + would simply be too easy for changes to become orphaned when 1.451 + files are renamed.</para> 1.452 + 1.453 + </sect2> 1.454 + <sect2> 1.455 + <title>Divergent renames and merging</title> 1.456 + 1.457 + <para id="x_1da">The case of diverging names occurs when two developers 1.458 + start with a file&emdash;let's call it 1.459 + <filename>foo</filename>&emdash;in their respective 1.460 + repositories.</para> 1.461 + 1.462 + &interaction.rename.divergent.clone; 1.463 + 1.464 + <para id="x_1db">Anne renames the file to <filename>bar</filename>.</para> 1.465 + 1.466 + &interaction.rename.divergent.rename.anne; 1.467 + 1.468 + <para id="x_1dc">Meanwhile, Bob renames it to 1.469 + <filename>quux</filename>.</para> 1.470 + 1.471 + &interaction.rename.divergent.rename.bob; 1.472 + 1.473 + <para id="x_1dd">I like to think of this as a conflict because each 1.474 + developer has expressed different intentions about what the 1.475 + file ought to be named.</para> 1.476 + 1.477 + <para id="x_1de">What do you think should happen when they merge their 1.478 + work? Mercurial's actual behaviour is that it always preserves 1.479 + <emphasis>both</emphasis> names when it merges changesets that 1.480 + contain divergent renames.</para> 1.481 + 1.482 + &interaction.rename.divergent.merge; 1.483 + 1.484 + <para id="x_1df">Notice that Mercurial does warn about the divergent 1.485 + renames, but it leaves it up to you to do something about the 1.486 + divergence after the merge.</para> 1.487 + 1.488 + </sect2> 1.489 + <sect2> 1.490 + <title>Convergent renames and merging</title> 1.491 + 1.492 + <para id="x_1e0">Another kind of rename conflict occurs when two people 1.493 + choose to rename different <emphasis>source</emphasis> files 1.494 + to the same <emphasis>destination</emphasis>. In this case, 1.495 + Mercurial runs its normal merge machinery, and lets you guide 1.496 + it to a suitable resolution.</para> 1.497 + 1.498 + </sect2> 1.499 + <sect2> 1.500 + <title>Other name-related corner cases</title> 1.501 + 1.502 + <para id="x_1e1">Mercurial has a longstanding bug in which it fails to 1.503 + handle a merge where one side has a file with a given name, 1.504 + while another has a directory with the same name. This is 1.505 + documented as <ulink role="hg-bug" 1.506 + url="http://www.selenic.com/mercurial/bts/issue29">issue 1.507 + 29</ulink>.</para> 1.508 + 1.509 + &interaction.issue29.go; 1.510 + 1.511 + </sect2> 1.512 + </sect1> 1.513 + <sect1> 1.514 + <title>Recovering from mistakes</title> 1.515 + 1.516 + <para id="x_1e2">Mercurial has some useful commands that will help you to 1.517 + recover from some common mistakes.</para> 1.518 + 1.519 + <para id="x_1e3">The <command role="hg-cmd">hg revert</command> command lets 1.520 + you undo changes that you have made to your working directory. 1.521 + For example, if you <command role="hg-cmd">hg add</command> a 1.522 + file by accident, just run <command role="hg-cmd">hg 1.523 + revert</command> with the name of the file you added, and 1.524 + while the file won't be touched in any way, it won't be tracked 1.525 + for adding by Mercurial any longer, either. You can also use 1.526 + <command role="hg-cmd">hg revert</command> to get rid of 1.527 + erroneous changes to a file.</para> 1.528 + 1.529 + <para id="x_1e4">It's useful to remember that the <command role="hg-cmd">hg 1.530 + revert</command> command is useful for changes that you have 1.531 + not yet committed. Once you've committed a change, if you 1.532 + decide it was a mistake, you can still do something about it, 1.533 + though your options may be more limited.</para> 1.534 + 1.535 + <para id="x_1e5">For more information about the <command role="hg-cmd">hg 1.536 + revert</command> command, and details about how to deal with 1.537 + changes you have already committed, see chapter <xref 1.538 + linkend="chap.undo"/>.</para> 1.539 + 1.540 + </sect1> 1.541 +</chapter> 1.542 + 1.543 +<!-- 1.544 +local variables: 1.545 +sgml-parent-document: ("00book.xml" "book" "chapter") 1.546 +end: 1.547 +-->