← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/user-guide/undoing_mistakes.txt

(jameinel) Allow 'bzr serve' to interpret SIGHUP as a graceful shutdown.
 (bug #795025) (John A Meinel)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/user-guide/undoing_mistakes.txt
10
10
Dropping the revision history for a project
11
11
-------------------------------------------
12
12
 
13
 
If you accidently put the wrong tree under version control, simply
 
13
If you accidentally put the wrong tree under version control, simply
14
14
delete the ``.bzr`` directory.
15
15
 
16
16
Deregistering a file or directory
17
17
---------------------------------
18
18
 
19
 
If you accidently register a file using ``add`` that you
 
19
If you accidentally register a file using ``add`` that you
20
20
don't want version controlled, you can use the ``remove``
21
21
command to tell Bazaar to forget about it.
22
22
 
93
93
one or more files. Some users like to alias ``commit`` to ``commit --strict``
94
94
so that commits fail if unknown files are found in the tree.
95
95
 
 
96
Tags for uncommitted revisions are removed from the branch unless
 
97
``--keep-tags`` was specified.
 
98
 
96
99
Note: While the ``merge`` command is not introduced until the next
97
100
chapter, it is worth noting now that ``uncommit`` restores any pending
98
101
merges. (Running ``bzr status`` after ``uncommit`` will show these.)
99
102
``merge`` can also be used to effectively undo just a selected commit
100
 
earlier in history. For more information on ``merge``, see `Merging changes`_
101
 
in the next chapter and the Bazaar User Reference.
 
103
earlier in history. For more information on ``merge``, see
 
104
`Merging changes <merging_changes.html>`_ in the next chapter and the
 
105
Bazaar User Reference.
102
106
 
103
107
Undoing multiple commits
104
108
------------------------
132
136
This will change your entire tree back to the state as of revision 19,
133
137
which is probably only what you want if you haven't made any new commits
134
138
since then. If you have, the ``revert`` would wipe them out as well. In that
135
 
case, you probably want to use `Reverse cherrypicking`_ instead to
 
139
case, you probably want to use `Reverse cherrypicking
 
140
<adv_merging.html#reverse-cherrypicking>`_ instead to
136
141
back out the bad fix.
137
142
 
138
143
Note: As an alternative to using an absolute revision number (like 19), you can