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
Define manager interfaces and update all of Gitblit to use managers
These manager interfaces define how the GitBlit singleton will
eventually be split into smaller component managers. The Wicket app and
all servlets have been updated to request the needed managers. There
are _very_ few method signature changes - although there are a handful.
This is a surgical sharding of responsibility based on a proof of
concept refactor. Instead of random references to GittBlit.self()
there are now precise references to the manager interface required to
accomplish some task. Some tasks may require references to multiple
managers.
The code is now littered with calls to GitBlit.getManager(class) and
those familiar with the code-base will no doubt notice the duplication
of methods from IUserService in IUserManager and the addition of
implementation methods in the GitBlit context class. When the
GitBlit class is broken apart and the existing external authentication
user service classes are refactored to AuthenticationService classes,
this will again simplify and flatten. But in order to safely and
cleanly modularize the stable code-base we will have to live with a
little duplication for a short while.
Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
Eliminate nearly all direct GitBlit singleton references in Wicket
This is the first step towards modularization and injection. All
direct references to the GitBlit singleton within the Wicket pages
and panels have been replaced to proxy methods in the GitBlitWebApp
singleton. There are still two Wicket classes which rely on the
GitBlit singleton; those require manual instantiation (servlet 3).
Change-Id: I0cdbbcf87959d590c446c99abb09c07c87c737bc
Renamed pushlog to reflog to better match it's current and future purpose.
Split PushesPanel into ReflogPanel and DigestsPanel.
Overhauled project pages and gave them a coherent purpose from the dashboard.
Reorganized to Apache Standard Directory Layout & integrated Moxie
This is a massive commit which reorganizes the entire project structure
(although it is still monolithic), removes the Build classes, and
switches to Moxie, a smarter Ant build tookit based on the original
Gitblit Build classes.
The Ant build script will likely require additional fine-tuning, but
this is big step forward.
Preliminary implementation of server-side forking (issue 137)
The fork mechanism clones the repository , access restrictions, and
other config options. The app has been updated throughout to handle
personal repositories and to properly display origin/fork links.
In order to fork a repository the user account must have the #fork role,
the origin repository must permit forking, and the user account must
have standard clone permissions to the repository.
Because forking introduces a new user role no existing user accounts can
automatically begin forking a repository. This is both a pro and a con.
Since the fork has the same access restrictions as the origin repository,
those who can access the origin may also access the fork. This is intentional
to facilitate integration-manager workflow. The fork owner does have the
power to completely change the access restrictions of his/her fork.
Draft project pages, project metadata, and RSS feeds
This is an in-progress feature to offer an interface for grouped
repositories. This may help installations with large numbers of
repositories stay organized. It also will be part of a future,
more advanced security model.
Tighter Gravatar integration. New window/tab on most activity links.
Each Gravatar thumbnail is now a link to the Gitblit Gravatar profile
page. This page displays some of the profile information and contains a
link to the full Gravatar profile.
Activity page links now launch a new window/tab instead of targeting
"self" since it can be expensive to requery the activity information.
Added AccessRestrictionFilter and simplified authentication.
Replaced servlet container basic authentication with a custom servlet
filter which performs the same function. The advantage to this is
that the servlet container is now divorced from the webapp.
The login service (realm) also simplified a great deal and removes its
Jetty dependencies.
Additionally, the basic authorization pop-up will be displayed as
needed based on the repository's access restriction. This was
necessary for view-restricted repositories with the RSS feature. Its
also necessary for completely open repositories as before it would
prompt for credentials.
Improved feed syndication feature.
James Moger
kxyfyh
Lukasz Jader
Laurens Vrijnsen