~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2008-09-02 06:24:16 UTC
  • mfrom: (3635.1.3 integration)
  • Revision ID: pqm@pqm.ubuntu.com-20080902062416-dxdxccqki90bcynl
(robertc) Fix repack operations on SMB connections. (Robert Collins,
        bug 255656).

Show diffs side-by-side

added added

removed removed

Lines of Context:
10
10
Dropping the revision history for a project
11
11
-------------------------------------------
12
12
 
13
 
If you accidentally put the wrong tree under version control, simply
 
13
If you accidently 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 accidentally register a file using ``add`` that you
 
19
If you accidently 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
 
 
99
96
Note: While the ``merge`` command is not introduced until the next
100
97
chapter, it is worth noting now that ``uncommit`` restores any pending
101
98
merges. (Running ``bzr status`` after ``uncommit`` will show these.)
102
99
``merge`` can also be used to effectively undo just a selected commit
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.
 
100
earlier in history. For more information on ``merge``, see `Merging changes`_
 
101
in the next chapter and the Bazaar User Reference.
106
102
 
107
103
Undoing multiple commits
108
104
------------------------
136
132
This will change your entire tree back to the state as of revision 19,
137
133
which is probably only what you want if you haven't made any new commits
138
134
since then. If you have, the ``revert`` would wipe them out as well. In that
139
 
case, you probably want to use `Reverse cherrypicking
140
 
<adv_merging.html#reverse-cherrypicking>`_ instead to
 
135
case, you probably want to use `Reverse cherrypicking`_ instead to
141
136
back out the bad fix.
142
137
 
143
 
Note: As an alternative to using an absolute revision number (like 19), you can
 
138
Note: As an alternative to using an absolute bug number (like 19), you can
144
139
specify one relative to the tip (-1) using a negative number like this::
145
140
 
146
141
  bzr revert -r -2