progit
diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc
@@ -137,7 +137,7 @@ image::images/interesting-rebase-5.png[Final commit history.]
 (((rebasing, perils of)))
 Ahh, but the bliss of rebasing isn't without its drawbacks, which can be summed up in a single line:
 
-*Do not rebase commits that exist outside your repository.*
+*Do not rebase commits that exist outside your repository and people may have based work on them.*
 
 If you follow that guideline, you'll be fine.
 If you don't, people will hate you, and you'll be scorned by friends and family.
@@ -208,7 +208,8 @@ Or you could do it manually with a `git fetch` followed by a `git rebase teamone
 
 If you are using `git pull` and want to make `--rebase` the default, you can set the `pull.rebase` config value with something like `git config --global pull.rebase true`.
 
-If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you'll be fine.
+If you only ever rebase commits that have never left your own computer, you'll be just fine.
+If you rebase commits that have been pushed, but that no one else has based commits from, you'll also be fine.
 If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble, and the scorn of your teammates.
 
 If you or a partner does find it necessary at some point, make sure everyone knows to run `git pull --rebase` to try to make the pain after it happens a little bit simpler.