1 files changed, 36 insertions, 7 deletions
diff --git a/src/site/tickets_using.mkd b/src/site/tickets_using.mkd
index 228cf925..6541ed8f 100644
--- a/src/site/tickets_using.mkd
+++ b/src/site/tickets_using.mkd
@@ -22,23 +22,27 @@ Because you are too lazy to create a ticket in the web ui first.  The proposal t
 
 Any authenticated user who can clone your repository.
 
+    git clone https://server/r/repo.git
+    cd repo
     git checkout -b mytopic
     ...add a single commit...
     git push origin HEAD:refs/for/new
-    git branch --set-upstream-to={remote}/ticket/{id}
+    # read ticket id from server output
+    git branch --set-upstream-to=origin/ticket/{id}
 
 ### Creating the first Patchset for an Existing Ticket
 
-If you have an existing ticket that does **not** yet have a proposed patchset you can push using the magic ref.
+If you have an existing ticket that does **not** yet have a proposed patchset you can push using the ticket branch ref.
 
 *Who can create the first patchset for an existing ticket?*
 
 Any authenticated user who can clone your repository.
 
-    git checkout -b mytopic
+    git clone https://server/r/repo.git
+    cd repo
+    git checkout -b ticket/{id}
     ...add one or more commits...
-    git push origin HEAD:refs/for/{id}
-    git branch --set-upstream-to={remote}/ticket/{id}
+    git push --set-upstream origin ticket/{id}
 
 ### Safely adding commits to a Patchset for an Existing Ticket
 
@@ -50,7 +54,8 @@ Any authenticated user who can clone your repository.
 4. Any user with write (RW) permissions to the repository
 
 
-    git checkout ticket/{id}
+    git fetch && git checkout ticket/{id}
+    git pull --ff-only
     ...add one or more commits...
     git push
 
@@ -60,10 +65,33 @@ Any authenticated user who can clone your repository.
 
 See the above rules for who can add commits to a patchset. You do **not** need rewind (RW+) to the repository to push a non-fast-forward patchset.  Gitblit will detect the non-fast-forward update and create a new patchset ref.  This preserves the previous patchset.
 
-    git checkout ticket/{id}
+    git fetch && git checkout ticket/{id}
+    git pull --ff-only
     ...amend, rebase, squash...
     git push origin HEAD:refs/for/{id}
 
+OR if you have RW+ permissions, then you can push using *-f* flag.
+
+    git push -f
+
+### Updating your copy of a rewritten Patchset
+
+If a patchset has been rewritten you can no longer simply *pull* to update.  Let's assume your checkout *does not* have any unshared commits - i.e. it represents the previous patchset.  The simplest way to update your branch to the current patchset is to reset it.
+
+    git fetch && git checkout ticket/{id}
+    git reset --hard origin/ticket/{id}
+
+If you *do* have unshared commits then you'll could make a new temporary branch and then cherry-pick your changes onto the rewritten patchset.
+
+    git branch oldticket ticket/{id}
+    git fetch && git checkout ticket/{id}
+    git reset --hard origin/ticket/{id}
+    git cherry-pick <commitid1> <commitid2>
+    git branch -D oldticket
+
+Since Git is a powerful and flexible tool, there are no doubt several other strategies you could use to resolve this situation.
+
+
 ### Ticket RefSpecs
 
 Gitblit supports two primary push ref specs: the magic ref and the patchset ref.
@@ -130,6 +158,7 @@ There are complicated merge scenarios for which it may be best to merge using yo
     git checkout master
     git merge ticket-{id}
     git push origin master
+    git branch -d ticket-{id}
 
 ### Closing Tickets on Push with a Completely New Patchset