| | |
| | | 1. The organizational unit of the Gitblit Tickets feature is the *ticket*. |
| | | 2. A *ticket* can be used to report a bug, request an enhancement, ask a question, etc. A ticket can also be used to collaborate on a *patchset* that addresses the request. |
| | | 3. A *patchset* is a series of commits from a merge base that exists in the target branch of your repository to the tip of the patchset. A patchset may only contain a single commit, or it may contain dozens. This is similar to the commits in a *Pull Request*. One important distinction here is that in Gitblit, each *Patchset* is developed on a separate branch and can be completely rewritten without losing the previous patchsets (this creates a new patchset). |
| | | 4. A *ticket* monitors the development of *patchsets* by tracking *revisions* to *patchsets*. The ticket alslo monitors rewritten patchsets. Each *patchset* is developed on it's own Git branch. |
| | | 4. A *ticket* monitors the development of *patchsets* by tracking *revisions* to *patchsets*. The ticket also monitors rewritten patchsets. Each *patchset* is developed on it's own Git branch. |
| | | |
| | | Tracking *patchsets* is similar in concept to Gerrit, but there is a critical difference. In Gerrit, *every* commit in the *patchset* has it's own ticket **AND** Git branch. In Gerrit, *patchsets* can be easily rewritten and for each rewritten commit, a new branch ref is created. This leads to an explosion in refs for the repository over time. In Gitblit, only the tip of the *patchset* gets a branch ref and this branch ref is updated, like a regular branch, unless a rewrite is detected. |
| | | |
| | |
| | | |
| | | Additionally, because the patchset is not linked to a user's personal fork it is possible to allow others to collaborate on development. |
| | | |
| | | ## Status |
| | | #### Features |
| | | |
| | | The Tickets feature is highly functional but there are several areas which need further refinements. |
| | | |
| | | #### What is working |
| | | |
| | | - My Tickets page |
| | | - Ticket creation and editing |
| | | - Ticket creation on patchset push |
| | | - Ticket creation on patchset push (proposal) |
| | | - Branch-based pull-requests |
| | | - Comments with Markdown syntax support |
| | | - Rich email notifications |
| | | - Fast-forward patchset updates and patchset rewrites |
| | | - Voting |
| | | - Watching |
| | | - Mentions |
| | | - Partial milestone support |
| | | - Milestones |
| | | - Querying |
| | | - Searching |
| | | - Is Mergeable test on view ticket page load |
| | | - Server-side merge |
| | | - Close-on-push of detected merge |
| | | - Multiple backend choices |
| | | - Server-side merge (testing) |
| | | |
| | | #### TODO |
| | | |
| | | - Implement a My Tickets page (ticket-15) |
| | | - Ticket Lifecycle Hooks (ticket-16) |
| | | - CRUD pages for Milestones (ticket-17) |
| | | - Ticket service migration tool (ticket-19) |
| | | - Collapsible ticket description (e.g. AUI expander) |
| | | - Edit a comment |
| | | - Delete a comment |
| | | - REST API for tooling |
| | | - Client-side Markdown previews (AngularMarkdown?) |