Fix skip summary metrics regression since introducing flotr2

Ting

2014-04-16 d0751dc352ef06c067593f31f5423fce357f8f1f

 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.