From b799d545f37f7123aaa1ee1d0ff3b61f1f3cc8c2 Mon Sep 17 00:00:00 2001
From: David Ostrovsky <david@ostrovsky.org>
Date: Thu, 10 Apr 2014 18:58:08 -0400
Subject: [PATCH] Add review SSH command
---
src/site/tickets_using.mkd | 51 +++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/src/site/tickets_using.mkd b/src/site/tickets_using.mkd
index 228cf92..7d9e569 100644
--- a/src/site/tickets_using.mkd
+++ b/src/site/tickets_using.mkd
@@ -22,35 +22,40 @@
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
*Who can add commits to an existing patchset?*
-1. The author of the ticket
-2. The author of the initial patchset
+1. The ticket author
+2. The initial patchset author
3. The person set as *responsible*
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,9 +65,32 @@
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
+
+Git is a very flexible tool, there are no doubt several other strategies you could use to resolve this situation. The above solution is just one way.
+
### Ticket RefSpecs
@@ -130,6 +158,7 @@
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
@@ -154,6 +183,8 @@
- -1, needs improvement: please do not merge
- -2, vetoed: patchset may not be merged
-Only users with write (RW) permissions to the repository can give a +2 and -2 score. All other users are allowed to score +/-1.
+Only users with write (RW) permissions to the repository can give a +2 and -2 score. All other users are allowed to score +/-1. If the repository is configured to *require approval* then then +2 score has an important meaning. The merge button will only be shown if there is at least one +2 score and no -2 scores. If there is a -2 score, the merge is blocked by the web ui. Users with RW permissions, however, can still manually merge and push the patchset to the integration branch; Gitblit does not enforce vetoed patchsets on push.
+
+#### Reviews and Updated or Rewritten Patchsets
If the patchset is updated or rewritten, all former review scores are ignored; review scores apply to specific revisions of patchsets - they are not blanket approvals/disapprovals.
--
Gitblit v1.9.1