# 
# patch "ChangeLog"
#  from [3d64a878f7ab1a4d86152743953dc51b6139e256]
#    to [450eb8cc70f3ce986b97d59155abb53300d1b448]
# 
# patch "monotone.texi"
#  from [38e796ddafa66c78001fb53209d8c7e0dd8c0b75]
#    to [beb10855718e7f99b7f666defd1ab2de5e5e81dd]
# 
--- ChangeLog
+++ ChangeLog
@@ -1,3 +1,8 @@
+2005-04-18  Nathaniel Smith  <address@hidden>
+
+	* monotone.texi (Dealing with a Fork): Clarify (hopefully) what we
+	mean when we say that "update" is a dangerous command.
+
 2005-04-17  Matt Johnston  <address@hidden>
 
 	* packet.cc: fix up unit test compilation.
--- monotone.texi
+++ monotone.texi
@@ -2096,10 +2096,27 @@
 (an update) and a ``post-commit'' merge. Both sorts of merge use the
 exact same algorithm. The major difference concerns the recoverability
 of the pre-merge state: if you commit your work first, and merge after
-committing, the merge can fail (due to difficulty in a manual merge
-step) and your committed state is still safe. It is therefore
-recommended that you commit your work @emph{first}, before merging.
+committing, then even if the merge somehow fails (due to difficulty in a
+manual merge step, for instance), your committed state is still safe.
+If you update, on the other hand, you are requesting that monotone
+directly modify your working copy, and while monotone will try hard not
+to break anything, this process is inherently more open to error.  It is
+therefore recommended that you commit your work @emph{first}, before
+merging.
 
+If you have previously used another version control system, this may at
+first seem surprising; there are some systems where you are
address@hidden to update, and risk the above problems, before you can
+commit.  Monotone, however, was designed with this problem in mind, and
+thus @emph{always} allows you to commit before merging.  A good rule of
+thumb is to only use @command{update} in working copies with no local
+modifications, or when you actually want to work against a different
+base revision (perhaps because finishing your change turns out to
+require some fixes made in another revision, or because you discover
+that you have accidentally started working against a revision that
+contains unrelated bugs, and need to back out to a working revision for
+testing).
+
 @page
 @node    Branching and Merging
 @section Branching and Merging