A basic issue tracker styled as a hybrid of GitHub and BitBucket issues.
You may attach commits to an existing ticket or you can push a single
commit to create a *proposal* ticket.
Tickets keep track of patchsets (one or more commits) and allow patchset
rewriting (rebase, amend, squash) by detecing the non-fast-forward
update and assigning a new patchset number to the new commits.
Ticket tracker
--------------
The ticket tracker stores tickets as an append-only journal of changes.
The journals are deserialized and a ticket is built by applying the
journal entries. Tickets are indexed using Apache Lucene and all
queries and searches are executed against this Lucene index.
There is one trade-off to this persistence design: user attributions are
non-relational.
What does that mean? Each journal entry stores the username of the
author. If the username changes in the user service, the journal entry
will not reflect that change because the values are hard-coded.
Here are a few reasons/justifications for this design choice:
1. commit identifications (author, committer, tagger) are non-relational
2. maintains the KISS principle
3. your favorite text editor can still be your administration tool
Persistence Choices
-------------------
**FileTicketService**: stores journals on the filesystem
**BranchTicketService**: stores journals on an orphan branch
**RedisTicketService**: stores journals in a Redis key-value datastore
It should be relatively straight-forward to develop other backends
(MongoDB, etc) as long as the journal design is preserved.
Pushing Commits
---------------
Each push to a ticket is identified as a patchset revision. A patchset
revision may add commits to the patchset (fast-forward) OR a patchset
revision may rewrite history (rebase, squash, rebase+squash, or amend).
Patchset authors should not be afraid to polish, revise, and rewrite
their code before merging into the proposed branch.
Gitblit will create one ref for each patchset. These refs are updated
for fast-forward pushes or created for rewrites. They are formatted as
`refs/tickets/{shard}/{id}/{patchset}`. The *shard* is the last two
digits of the id. If the id < 10, prefix a 0. The *shard* is always
two digits long. The shard's purpose is to ensure Gitblit doesn't
exceed any filesystem directory limits for file creation.
**Creating a Proposal Ticket**
You may create a new change proposal ticket just by pushing a **single
commit** to `refs/for/{branch}` where branch is the proposed integration
branch OR `refs/for/new` or `refs/for/default` which both will use the
default repository branch.
git push origin HEAD:refs/for/new
**Updating a Patchset**
The safe way to update an existing patchset is to push to the patchset
ref.
git push origin HEAD:refs/heads/ticket/{id}
This ensures you do not accidentally create a new patchset in the event
that the patchset was updated after you last pulled.
The not-so-safe way to update an existing patchset is to push using the
magic ref.
git push origin HEAD:refs/for/{id}
This push ref will update an exisitng patchset OR create a new patchset
if the update is non-fast-forward.
**Rebasing, Squashing, Amending**
Gitblit makes rebasing, squashing, and amending patchsets easy.
Normally, pushing a non-fast-forward update would require rewind (RW+)
repository permissions. Gitblit provides a magic ref which will allow
ticket participants to rewrite a ticket patchset as long as the ticket
is open.
git push origin HEAD:refs/for/{id}
Pushing changes to this ref allows the patchset authors to rebase,
squash, or amend the patchset commits without requiring client-side use
of the *--force* flag on push AND without requiring RW+ permission to
the repository. Since each patchset is tracked with a ref it is easy to
recover from accidental non-fast-forward updates.
Features
--------
- Ticket tracker with status changes and responsible assignments
- Patchset revision scoring mechanism
- Update/Rewrite patchset handling
- Close-on-push detection
- Server-side Merge button for simple merges
- Comments with Markdown syntax support
- Rich mail notifications
- Voting
- Mentions
- Watch lists
- Querying
- Searches
- Partial miletones support
- Multiple backend options
WindowsAuthProvider setting to restrict BUILTIN\Administrators
Some environments do not want to automatically allow Windows admin
accounts to be Gitblit admins. This patch allows disabling/enabling the
relationship between Windows builtin admin accounts and Gitblit accounts.
Remove admin permission setting from Redmine auth provider (issue-368)
This feature depended on an undocumented behavior of Redmine. If/when
Redmine groups are mapped to Gitblit teams, we can reconsider setting
the admin permission (issue-321).
issue-361: Reset user cookie after administrative password change
Cookies were not reset on administrative password change of a user
account. This allowed accounts with changed passwords to continue
authenticating. Cookies are now reset on password changes, they are
validated on each page request, AND they will now expire 7 days after
generation.
Combining Dagger and Servlet 3 works really well on stock Tomcat and
Jetty but it is a troublesome combination on JEE containers with their
own ideas on how to instantiate classes. JBoss AS 7 has been
particularly nasty and it is just simpler to scaleback and stay with
Servlet 2.5 than it is to fight all permuations of containers.
Instead of using constructor DI, the servlets and filters each have an
inject(ObjectGaph) method which is automatically called during
initialization. Each servlet or filter is responsible for retrieving
the required dependency from the graph. The Dagger object graph is
created in the context listener and stuffed into the context as an
attribute.
Change-Id: Ib5714584fe73e2a6b9c6fda12af080a43356cbda
Add support for per-repository bugtraq configuration
Imported the reference implementation contributed by syntevo which
is used in their SmartGit product. You may create a bugtraq config
section inf your .git/config file OR you may add a .gitbugtraq file
to the root of your repository.
Example:
[bugtraq "issues"]
url = http://code.google.com/p/gitblit/issues/detail?id=%BUGID%
logRegex = "[Ii]ssue[-#:\\s]{1}\\d+"
logRegex1 = "\\d+"
[bugtraq "[pullrequests"]
url = "https://github.com/gitblit/gitblit/pull/%BUGID%"
logRegex = "(?:pull request|pull|pr)\\s*[-#]?([0-9]+)"
Change-Id: Iaba305bf4280d08cc4d1abf533c2f1365470a43f
Add coloring modes to the blame page (issue-2, pull request #125)
Blame output is now colored according to Commit (default), Author or
Age. Both Commit and Author output uses random colors whereas Age uses a
single color with varying tints applied to indicate the age. White
indicates the eldest commit with the tint darkening as the commits get
younger.
Change-Id: I045458329af4765e91d5829ce3e8d28e21eeb66e
Currently the LDAP user service will not dereference aliases when
searching for groups. This patch enables dereferencing aliases for the
group search. This is benefitial if groups are defined in the DIT in a
common place but only certain ones shall play a role in Gitblit. These
can now be linked under a group that can be provided as search base for
groups, without having to recreate the existing groups under the search
base.
In addition, the new doSearch() method implemented in this patch also
limits the attributes returned for the group search to the "cn"
attribute, which is the only one used. That prevents returning all the
members of the result groups, which can be a lot.
Change-Id: I29e1560390810304386dcea5ca40aaf78601b3a9
James Moger
Alfred Schmid
Berke Viktor
David Ostrovsky
Alex Lewis
Florian Zschocke
Günter Dressel