revert misleading clarification, and try to clarify better
authorhttp://smcv.pseudorandom.co.uk/ <http://smcv.pseudorandom.co.uk/@web>
Sun, 28 Mar 2010 14:52:03 +0000 (14:52 +0000)
committerJoey Hess <joey@finch.kitenet.net>
Sun, 28 Mar 2010 14:52:03 +0000 (14:52 +0000)
doc/tips/spam_and_softwaresites.mdwn

index 78a35ff051c0fc15fdffe733d79004e1be00d016..507858c0cca3f5a9b3bfd70f7a1f662896ec4048 100644 (file)
@@ -82,5 +82,6 @@ Caveat: if there are no commits you want to keep (i.e. all the commits since
 the last merge into master are either spam or spam reverts) then `git rebase`
 will abort. Therefore, this approach only works if you have at least one
 non-spam commit to the documentation since the last merge into `master`. For
-this reason, it's best wait to tackle spam with reverts until you have at least one
-commit you want merged back into the main history.
+this reason, it's best to wait until you have at least one
+commit you want merged back into the main history before doing a rebase,
+and until then, tackle spam with reverts.