 Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago  Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Improve the commitdiff.
* Optimize CSS: simplify selectors. That alone cuts rendering time in
half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
Also move the +/- out of the code column; it also gets in the way
when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.
https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.
This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.
The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.
The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.
(Note that this technique could be used on other diff pages, too. For
instance on the blame page.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Add a blink comparator and pixel difference to image diffs
Pixel difference uses CSS mix-blend-mode, which is supported currently
only on Firefox >= 32 and on Safari >= 7.1. Implementation is behind a
Javascript feature test.
For other browsers, there's a blink comparator.
Code changes:
* ImageDiffHandler now takes the page it's used on as argument. We need
that to get labels. DOM generated is a
little bit different (new controls).
* Diff pages adapted to new constructor of ImageDiffHandler.
* CSS and Javascript changes implementing the new controls, making use
of two new static image resources. Since I felt that the new controls
deserved tooltips, I also gave the opacity slider a tooltip: changed
to <a>, and slider handle changed from <div> to <span>. CSS ensures
everything still displays the same (basically display:inline-block).
* Supplied messages for English, French, and German for the new
tooltips.
Tested on IE8, Safari 6.1.6 & 7.1, Chrome 38, FF 33.1 & FF 3.6.13 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Add a blink comparator and pixel difference to image diffs
Pixel difference uses CSS mix-blend-mode, which is supported currently
only on Firefox >= 32 and on Safari >= 7.1. Implementation is behind a
Javascript feature test.
For other browsers, there's a blink comparator.
Code changes:
* ImageDiffHandler now takes the page it's used on as argument. We need
that to get labels. DOM generated is a
little bit different (new controls).
* Diff pages adapted to new constructor of ImageDiffHandler.
* CSS and Javascript changes implementing the new controls, making use
of two new static image resources. Since I felt that the new controls
deserved tooltips, I also gave the opacity slider a tooltip: changed
to <a>, and slider handle changed from <div> to <span>. CSS ensures
everything still displays the same (basically display:inline-block).
* Supplied messages for English, French, and German for the new
tooltips.
Tested on IE8, Safari 6.1.6 & 7.1, Chrome 38, FF 33.1 & FF 3.6.13 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Add a blink comparator and pixel difference to image diffs
Pixel difference uses CSS mix-blend-mode, which is supported currently
only on Firefox >= 32 and on Safari >= 7.1. Implementation is behind a
Javascript feature test.
For other browsers, there's a blink comparator.
Code changes:
* ImageDiffHandler now takes the page it's used on as argument. We need
that to get labels. DOM generated is a
little bit different (new controls).
* Diff pages adapted to new constructor of ImageDiffHandler.
* CSS and Javascript changes implementing the new controls, making use
of two new static image resources. Since I felt that the new controls
deserved tooltips, I also gave the opacity slider a tooltip: changed
to <a>, and slider handle changed from <div> to <span>. CSS ensures
everything still displays the same (basically display:inline-block).
* Supplied messages for English, French, and German for the new
tooltips.
Tested on IE8, Safari 6.1.6 & 7.1, Chrome 38, FF 33.1 & FF 3.6.13 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Add a blink comparator and pixel difference to image diffs
Pixel difference uses CSS mix-blend-mode, which is supported currently
only on Firefox >= 32 and on Safari >= 7.1. Implementation is behind a
Javascript feature test.
For other browsers, there's a blink comparator.
Code changes:
* ImageDiffHandler now takes the page it's used on as argument. We need
that to get labels. DOM generated is a
little bit different (new controls).
* Diff pages adapted to new constructor of ImageDiffHandler.
* CSS and Javascript changes implementing the new controls, making use
of two new static image resources. Since I felt that the new controls
deserved tooltips, I also gave the opacity slider a tooltip: changed
to <a>, and slider handle changed from <div> to <span>. CSS ensures
everything still displays the same (basically display:inline-block).
* Supplied messages for English, French, and German for the new
tooltips.
Tested on IE8, Safari 6.1.6 & 7.1, Chrome 38, FF 33.1 & FF 3.6.13 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Add a blink comparator and pixel difference to image diffs
Pixel difference uses CSS mix-blend-mode, which is supported currently
only on Firefox >= 32 and on Safari >= 7.1. Implementation is behind a
Javascript feature test.
For other browsers, there's a blink comparator.
Code changes:
* ImageDiffHandler now takes the page it's used on as argument. We need
that to get labels. DOM generated is a
little bit different (new controls).
* Diff pages adapted to new constructor of ImageDiffHandler.
* CSS and Javascript changes implementing the new controls, making use
of two new static image resources. Since I felt that the new controls
deserved tooltips, I also gave the opacity slider a tooltip: changed
to <a>, and slider handle changed from <div> to <span>. CSS ensures
everything still displays the same (basically display:inline-block).
* Supplied messages for English, French, and German for the new
tooltips.
Tested on IE8, Safari 6.1.6 & 7.1, Chrome 38, FF 33.1 & FF 3.6.13 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Javascript-based sliders styled with CSS
This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):
1. For very small images the red resize handle would overlap the image
itself. In that case, the image became un-draggable as soon as the
opacity was reduced below 1.0.
2. Safari apparently doesn't send mousemove events during a CSS
resize, so the opacity was changed only on mouseup.
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.
Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.
imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.
(imgdiff.js also sets up the ese sliders on the diff pages.) 9 years ago Add a blink comparator and pixel difference to image diffs
Pixel difference uses CSS mix-blend-mode, which is supported currently
only on Firefox >= 32 and on Safari >= 7.1. Implementation is behind a
Javascript feature test.
For other browsers, there's a blink comparator.
Code changes:
* ImageDiffHandler now takes the page it's used on as argument. We need
that to get labels. DOM generated is a
little bit different (new controls).
* Diff pages adapted to new constructor of ImageDiffHandler.
* CSS and Javascript changes implementing the new controls, making use
of two new static image resources. Since I felt that the new controls
deserved tooltips, I also gave the opacity slider a tooltip: changed
to <a>, and slider handle changed from <div> to <span>. CSS ensures
everything still displays the same (basically display:inline-block).
* Supplied messages for English, French, and German for the new
tooltips.
Tested on IE8, Safari 6.1.6 & 7.1, Chrome 38, FF 33.1 & FF 3.6.13 9 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago Ticket tracker with patchset contributions
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
10 years ago |
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500150115021503150415051506150715081509151015111512151315141515151615171518151915201521152215231524152515261527152815291530153115321533153415351536153715381539154015411542154315441545154615471548154915501551155215531554155515561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608160916101611161216131614161516161617161816191620162116221623162416251626162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650165116521653165416551656165716581659166016611662166316641665166616671668166916701671167216731674167516761677167816791680168116821683168416851686168716881689169016911692169316941695169616971698169917001701170217031704170517061707170817091710171117121713171417151716171717181719172017211722172317241725172617271728172917301731173217331734173517361737173817391740174117421743174417451746174717481749175017511752175317541755175617571758175917601761176217631764176517661767176817691770177117721773177417751776177717781779178017811782178317841785178617871788178917901791179217931794179517961797179817991800180118021803180418051806180718081809181018111812181318141815181618171818181918201821182218231824182518261827182818291830183118321833183418351836183718381839184018411842184318441845184618471848184918501851185218531854185518561857185818591860186118621863186418651866186718681869187018711872187318741875187618771878187918801881188218831884188518861887188818891890189118921893189418951896189718981899190019011902190319041905190619071908190919101911191219131914191519161917191819191920192119221923192419251926192719281929193019311932193319341935193619371938193919401941194219431944194519461947194819491950195119521953195419551956195719581959196019611962196319641965196619671968196919701971197219731974197519761977197819791980198119821983198419851986198719881989199019911992199319941995199619971998199920002001200220032004200520062007200820092010201120122013201420152016201720182019202020212022202320242025202620272028202920302031203220332034203520362037203820392040204120422043204420452046204720482049205020512052205320542055205620572058205920602061206220632064206520662067206820692070207120722073207420752076207720782079208020812082208320842085208620872088208920902091209220932094209520962097209820992100210121022103210421052106210721082109211021112112211321142115211621172118211921202121212221232124212521262127212821292130213121322133213421352136213721382139214021412142214321442145214621472148214921502151215221532154215521562157215821592160216121622163216421652166216721682169217021712172217321742175217621772178217921802181218221832184218521862187218821892190219121922193219421952196219721982199220022012202220322042205220622072208220922102211221222132214221522162217221822192220222122222223222422252226222722282229223022312232223322342235223622372238223922402241224222432244224522462247224822492250225122522253225422552256225722582259226022612262226322642265226622672268226922702271227222732274227522762277227822792280228122822283228422852286228722882289229022912292229322942295229622972298229923002301230223032304230523062307230823092310231123122313231423152316231723182319232023212322232323242325232623272328232923302331233223332334233523362337233823392340234123422343234423452346234723482349235023512352235323542355235623572358 |
- body {
- /* 47px is the header height */
- padding-top: 47px;
- }
-
- footer {
- margin-top: 25px;
- padding: 15px 0 16px;
- border-top: 1px solid #E5E5E5;
- }
-
- body, input, select {
- color: #202020;
- }
-
- ul, ol {
- margin-bottom: 10px !important;
- }
-
- a {
- color: #2F58A0;
- }
-
- a:hover {
- color: #002060;
- }
-
- a:focus {
- outline: none;
- }
-
- a.btn i {
- /* override for a links that look like bootstrap buttons */
- vertical-align: text-bottom;
- }
-
- a.bugtraq {
- font-weight: bold;
- }
-
- .gray {
- color: #888;
- }
-
- .octicon-centered {
- text-align: center;
- width: 16px;
- }
-
- tr:hover .octicon-centered {
- color:#eee;
- }
-
- .label a.bugtraq {
- font-weight: normal;
- color: white;
- }
-
- .lwbadge {
- color: #888;
- font-size: 11px;
- background-color: #e8e8e8;
- padding: 1px 7px 2px;
- -webkit-border-radius: 9px;
- -moz-border-radius: 9px;
- border-radius: 9px;
- line-height: 14px;
- white-space: nowrap;
- vertical-align: baseline;
- }
-
- [class^="icon-"], [class*=" icon-"] i {
- /* override for a links that look like bootstrap buttons */
- vertical-align: text-bottom;
- }
-
- .pagination-small, .pagination-small ul {
- margin: 0px !important;
- }
-
- .pagination-small ul {
- border-right: 1px solid #ddd;
- }
-
- .pagination-small ul > li > a,
- .pagination-small ul > li > span {
- padding: 2px 8px;
- font-size: 13px;
- line-height: 22px;
- border: 1px solid #ddd;
- border-right: 0px;
- border-radius: 0px !important;
- float: left;
- }
-
- .btn.disabled em, .pagination-small ul > li > span em {
- font-style: normal;
- color: #444;
- }
-
- hr {
- margin-top: 10px;
- margin-bottom: 10px;
- }
-
- .settings th {
- vertical-align: top;
- }
-
- .pageTitle {
- padding-bottom: 5px;
- margin: 0;
- border-bottom: 1px solid #eee;
- }
-
- .pageTitle h1, .pageTitle h2 {
- color: #0069D6;
- }
-
- .navbar .brand {
- padding: 0px 10px 0px 20px;
- }
- .navbar .btn-navbar {
- margin-top: 10px;
- }
-
- .navbar .pull-right {
- margin: 0;
- }
-
- .navbar ul.nav {
- margin: 0 !important;
- padding: 4px 0px 0px 0px;
- }
-
- .navbar ul.nav li a {
- color: white;
- text-shadow: none;
- outline: 0;
- }
-
- .navbar ul.nav li a:hover {
- color: #abd4ff !important;
- text-decoration: underline;
- }
-
- .navbar .nav .active > a:hover {
- text-decoration: underline;
- }
-
- .navbar-inner {
- background-color: #002060;
- background-image: none;
- box-shadow: none;
- border-bottom: 1px solid #002060 !important;
- }
-
- .navbar ul li:focus, .navbar .active {
- outline: 0;
- padding-bottom: 1px;
- border-bottom: 3px solid #ff9900;
- margin-bottom: -1px;
- }
-
- ul.nav {
- border-color: #ccc;
- }
-
- .nav-tabs > .active > a,
- .nav-tabs > .active > a:hover {
- border: 1px solid #ccc;
- border-bottom-color: transparent;
- }
-
- .navbar .active a {
- background-color: transparent !important;
- outline: 0;
- }
-
- .navbar div > ul .menu-dropdown .selected, .nav .menu-dropdown .selected, .navbar div > ul .dropdown-menu .selected, .nav .dropdown-menu .selected {
- background-image: url("bullet_blue.png");
- background-repeat: no-repeat;
- background-position: left;
- }
-
- .navbar div>ul .dropdown-menu li a {
- color: #555;
- }
-
- navbar div>ul .menu-dropdown li a:hover,.nav .menu-dropdown li a:hover,.navbar div>ul .dropdown-menu li a:hover,.nav .dropdown-menu li a:hover{
- background-color: #000070;
- color: #ffffff !important;
- }
-
- .nav-pills > .active > a, .nav-pills > .active > a:hover,
- .nav-list > .active > a, .nav-list > .active > a:hover {
- color: #fff;
- background-color: #002060;
- }
-
- div.reflog {
- border-bottom: 1px solid #ddd;
- margin-bottom: 5px;
- padding-bottom: 5px;
- }
-
- div.reflog .icon {
- font-size: 42px;
- line-height: 42px;
- }
-
- div.reflog .when {
- color: #aaa;
- }
-
- div.reflog i {
- font-size: 42px;
- color: #bbb;
- vertical-align: middle;
- }
-
- div.reflog td.header {
- padding-left: 7px;
- vertical-align:middle;
- }
-
- div.reflog td.commits {
- padding-left: 7px;
- }
-
- div.reflog tr.commit td {
- vertical-align:top;
- padding-left: 5px;
- }
-
- div.reflog tr.commit img {
- max-width: none;
- }
-
- div.dashboardTitle {
- font-size: 1.75em;
- padding: 10px 0px 5px 0px;
- margin: 10px 0px;
- border-bottom: 1px solid #ccc;
- }
-
- div.dashboardTitle small {
- color: #888;
- font-size: 0.7em;
- }
-
- .repositorynavbar {
- background-color: #f8f8f8;
- border-bottom: 1px solid #ccc;
- margin-bottom: 10px;
- }
-
- .repositorynavbar .title {
- padding: 10px 0px;
- }
-
- .repositorynavbar .repository {
- font-weight: bold;
- }
-
- .title .repository a, .repositorynavbar .project a, .repositorynavbar .repository a {
- font-family: Helvetica,arial,freesans,clean,sans-serif;
- font-size: 22px;
- color: #002060;
- }
-
- .repositorynavbar .repositorynavbar-inner {
- padding-top: 2px;
- }
-
- .repositorynavbar ul {
- list-style: none outside;
- display: block;
- position: relative;
- border-top: 1px solid #ccc;
- }
-
- .repositorynavbar ul li {
- display: block;
- float: left;
- padding: 10px;
- }
-
- .repositorynavbar ul li:focus, .repositorynavbar .active {
- color: black;
- background-repeat:no-repeat;
- background-image: url(arrow_project.png);
- background-position: center bottom;
- font-weight: bold;
- outline: 0;
- }
-
- .repositorynavbar ul a {
- color: #002060;
- }
-
- .repositorynavbar ul li:hover {
- background-color: #eee;
- }
-
- .repositorynavbar ul li a:hover {
- background-color: inherit;
- text-decoration: underline;
- }
-
- @media (max-width: 767px) {
- .repositorynavbar {
- margin-right: -20px;
- margin-left: -20px;
- padding: 0px 5px;
- }
- }
-
- .btn-appmenu {
- border-radius: 4px !important;
- background-color: #002060;
- background-image:-khtml-gradient(linear, left top, left bottom, from(#4060A0), to(#002060));
- background-image:-moz-linear-gradient(center top, #4060A0, #002060);
- background-image:-ms-linear-gradient(top, #4060A0, #002060);
- background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #4060A0), color-stop(100%, #002060));
- background-image:-webkit-linear-gradient(top, #4060A0, #002060);
- background-image:-o-linear-gradient(top, #4060A0, #002060);
- background-image:linear-gradient(top, #4060A0, #002060);
-
- background-repeat: repeat-x;
- border-color: rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.25);
- color: #ffffff;
- text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.25);
- }
-
- .btn-appmenu:hover, .btn-appmenu:active, .btn-appmenu.active, .btn-appmenu.disabled, .btn-appmenu[disabled] {
- background-color: #002060;
- color: #ffffff;
- text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.25);
- }
-
-
- .btn-appmenu .caret {
- border-bottom-color: #FFFFFF;
- border-top-color: #FFFFFF;
- opacity: 0.75;
- }
-
- .breadcrumb {
- margin-top: 10px !important;
- margin-bottom: 10px !important;
- }
-
- .pageTitle {
- margin-bottom: 5px;
- }
-
- .pageTitle h2 small {
- font-size: 80%;
- font-weight: bold;
- }
-
- .pageTitle {
- color: #888;
- font-size: 18px;
- line-height: 27px;
- }
- .pageTitle .project, .pageTitle .repository {
- font-family: Helvetica, arial, freesans, clean, sans-serif;
- font-size: 22px;
- }
-
- .pageTitle .controls {
- font-size: 12px;
- }
-
- .pageTitle .repository {
- font-weight: bold;
- }
-
- .originRepository {
- font-family: Helvetica, arial, freesans, clean, sans-serif;
- color: #888;
- font-size: 12px;
- line-height: 14px;
- margin: 0px;
- }
-
- .forkSource, .forkEntry {
- color: #888;
- }
-
- .forkSource {
- font-size: 18px;
- line-height: 20px;
- padding: 5px 0px;
- }
-
- .forkEntry {
- font-size: 14px;
- padding: 2px 0px;
- }
-
- .forkSource .forks, .forkEntry .forks {
- font-size: 10px;
- padding-left: 5px;
- text-decoration: underline;
- vertical-align: middle;
- }
-
- div.repositoryUrlContainer {
- padding: 2px;
- background-color: #F5F5F5;
- background-image: -moz-linear-gradient(center top , #FFFFFF, #E6E6E6);
- background-repeat: repeat-x;
- border-color: #E6E6E6 #E6E6E6 #B3B3B3;
- border-image: none;
- border-radius: 4px;
- border-style: solid;
- border-width: 1px;
- box-shadow: 0 1px 0 rgba(255, 255, 255, 0.2) inset, 0 1px 2px rgba(0, 0, 0, 0.05);
- color: #333333;
- vertical-align: middle;
- border-color: rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.25);
- }
-
- div.repositoryUrlContainer:hover {
- background-color: #E6E6E6;
- background-position: 0 -15px;
- color: #333333;
- text-decoration: none;
- transition: background-position 0.1s linear 0s;
- }
-
- div.repositoryUrlContainer:hover .caret {
- opacity: 1;
- }
-
- div.repositoryUrlContainer:hover a:hover {
- text-decoration: none;
- }
-
- span.repositoryUrlLeftCap, span.repositoryUrlRightCap {
- text-align: center;
- color: black;
- padding: 3px;
- font-size: 11px;
- }
-
- span.repositoryUrlRightCap {
- font-weight: bold;
- font-family:menlo,consolas,monospace;
- }
-
- div.repositoryUrl {
- display: inline-block;
- font-size: 1em;
- padding: 1px 4px 2px 4px;
- background-color: #fff;
- border: 1px solid #ddd;
- margin: 1px;
- }
-
- div.repositoryIndicator {
- display:inline;
- padding-top:0px;
- margin-bottom:0px;
- }
-
- div.repositoryIndicator span.alert {
- padding: 2px 7px 2px 7px;
- vertical-align: middle;
- font-size:0.85em;
- font-weight:normal;
- }
-
- ul.urlMenu {
- min-width: 350px;
- }
-
- ul.urlMenu li.url {
- background-color: white;
- padding: 0px 5px;
- line-height: 24px;
- }
-
- ul.applicationMenu {
- background-color: whiteSmoke;
- min-width: 400px;
- }
-
- ul.applicationMenu li.action {
- background-color: white;
- padding: 0px 5px;
- line-height: 24px;
- }
-
- span.applicationTitle, span.applicationTitle a {
- display: inline;
- font-weight: bold;
- font-size:1.1em;
- color: black !important;
- padding: 0px;
- }
-
- div.applicationHeaderMenuItem {
- padding-left: 10px;
- color: black;
- }
-
- div.applicationLegalMenuItem {
- padding-left: 10px;
- color: #999;
- font-size: 0.85em;
- }
-
- a.applicationMenuItem, span.commandMenuItem {
- padding: 3px 10px;
- color: black;
- display: inline;
- padding: 0px;
- }
-
- span.commandMenuItem {
- font-size: 0.85em;
- font-family: menlo,consolas,monospace;
- }
-
- div.odd {
-
- }
-
- div.even {
- background-color: whiteSmoke;
- vertical-align: middle;
- }
-
- span.authorizationControl label {
- display: inline;
- color: #777;
- padding:5px 0px 5px 10px;
- }
-
- div.page_footer {
- clear: both;
- height: 17px;
- color: black;
- background-color: #ffffff;
- padding: 5px;
- border-top: 1px solid #bbb;
- font-style: italic;
- }
-
- pre, code, pre.prettyprint, pre.plainprint {
- background-color: #ffffff;
- color: black;
- font-family: monospace;
- font-size:12px;
- border:0px;
- padding: 0;
- line-height: 1.35em;
- }
-
- table {
- margin-bottom: 5px;
- font-size: inherit;
- }
-
- .table th {
- vertical-align: top;
- }
-
- th {
- vertical-align: middle;
- text-align: left;
- }
-
- table.tickets {
- border-bottom: 1px solid #ccc;
- }
-
- table.tickets td.indicators {
- width: 75px;
- text-align: right;
- padding-right: 5px;
- color: #888;
- }
-
- .ticketLabel,
- table.tickets .label {
- color: white;
- font-weight: normal;
- margin: 0px 2px;
- }
-
- div.featureWelcome {
- padding: 15px;
- background-color: #fbfbfb;
- border: 1px solid #ccc;
- border-radius: 5px;
- }
-
- div.featureWelcome div.icon {
- color: #ccc;
- font-size: 144px;
- }
-
- li.dynamicQuery {
- padding: 3px 0px;
- margin: 1px 0px;
- border-radius: 4px;
- }
-
- li.dynamicQuery i {
- color: rgba(255, 255, 255, 0.5);
- padding-right: 5px;
- }
-
- li.dynamicQuery a.active {
- color: white;
- }
-
- div.milestoneOverview {
- color:#888;
- border: 1px solid #ddd;
- padding: 2px 5px;
- text-align: center;
- font-size: 11px;
- background-color: #fbfbfb;
- }
-
- div.sourceview {
- overflow: hidden;
- }
-
- pre.prettyprint ol {
- padding-left:25px;
- }
-
- #nums {
- text-align: right;
- padding-right:10px;
- border-right:1px solid #ddd;
- font-family: monospace;
- line-height: 1.35em;
- vertical-align:top;
- }
-
- #nums pre {
- white-space: pre;
- }
-
- #nums pre, #lines pre {
- margin: 0;
- }
-
- #lines pre {
- padding: 0px !important;
- border: 0px !important;
- white-space: nowrap;
- }
-
- /* CSS trick to workaround #link topOfWindow offset problem */
- #nums .jump {
- border-top: 50px solid transparent;
- margin-top: -50px;
- background: url(arrow_line.png) no-repeat scroll bottom right transparent;
- }
-
- #nums .jump:target {
- border-left: 7px solid transparent;
- margin-right: 3px;
- }
-
- #lines .line {
- padding-left: 5px;
- color: #888;
- }
-
- #nums a:hover {
- background-color: #ffffbf;
- color: black;
- font-weight: bold;
- border-top: 1px solid red;
- border-bottom: 1px solid red;
- text-decoration: none;
- }
-
- #lines table {
- margin: 0;
- }
-
- #lines td {
- padding: 0;
- }
-
- #lines a {
- padding-left: 5px;
- }
-
- #lines tr:hover {
- background-color: #ffffbf;
- }
- #lines .odd {
- background-color: white;
- }
-
- #lines .even {
- background-color: #fafafa;
- }
-
- .diffstat {
- padding: 1px 5px;
- font-size: smaller;
- background-color: #f5f5f5;
- border: 1px solid #ccc;
- color: #ccc;
- font-weight:bold;
- display: inline-block;
- }
-
- .diffstat-inline {
- font-size: smaller;
- color: #ccc;
- font-weight:bold;
- }
-
- .diffstat .diffstat-total {
- color: black;
- border-right: 1px solid #ccc;
- padding-right: 4px;
- margin-right: 2px;
- }
-
- .diffstat-inline .diffstat-total {
- color: #999;
- padding-right: 2px;
- }
-
- .diffstat-segments {
- vertical-align: baseline;
- }
-
- .diffstat-insert {
- color: #629E62;
- }
-
- .diffstat-delete {
- color: #B9583B;
- }
- .patch-group {
- margin-bottom: 0px;
- border: 1px solid #ccc;
- background-color: #fbfbfb;
- }
-
- .patch-group .accordion-inner {
- padding: 0px;
- }
-
- .ticket-meta-top {
- padding: 0px 10px 10px 10px;
- }
-
- .ticket-meta-middle {
- border: 1px solid #ccc;
- padding: 10px;
- background-color: #fbfbfb;
- }
-
- .ticket-meta-bottom {
- border: 1px solid #ccc;
- border-top: 0px;
- padding: 10px;
- }
-
- .ticket-title {
- font-size: 20px;
- }
-
- .ticket-number {
- color: #ccc;
- font-size: 20px;
- font-weight: normal;
- }
-
- .ticket-list-icon {
- padding: 8px 0px 8px 8px !important;
- width: 24px;
- font-size: 24px;
- vertical-align: middle !important;
- color: #888;
- }
-
- td.ticket-list-state {
- vertical-align: middle;
- }
-
- td.ticket-list-priority {
- vertical-align: middle;
- }
-
- .ticket-list-details {
- font-size: 11px;
- color: #888;
- }
-
- div.ticket-text {
- max-width: 600px;
- }
-
- .ticket-text-editor {
- height:7em;
- border:0px;
- border-radius: 0px;
- border-top:1px solid #ccc;
- margin-bottom:0px;
- padding:4px;
- background-color:#ffffff;
- box-shadow: none;
- }
-
- .indicator-large-dark {
- font-size: 20px;
- color: #888;
- }
-
- .indicator-large-light {
- font-size: 20px;
- color: #bbb;
- }
-
- .indicator-huge-light {
- font-size: 48px;
- color: #bbb;
- }
-
- .attribution-emphasize {
- font-weight: bold;
- }
-
- .attribution-text {
- color: #888;
- }
-
- .attribution-border {
- }
-
- .attribution-header {
- background-color: #fbfbfb;
- padding: 8px;
- border: 1px solid #ccc;
- }
-
- .attribution-header-pullright {
- float: right;
- text-align: right;
- padding-right: 1px;
- }
-
- .attribution-patch-pullright {
- float: right;
- text-align: right;
- margin: 5px 10px;
- }
-
- .attribution-date {
- color: #999;
- font-size: smaller;
- }
-
- .attribution-link {
- color: #999;
- padding-left: 5px;
- }
-
- .attribution-pullright {
- float: right;
- text-align: right;
- padding-right: 8px;
- }
-
- .attribution-triangle {
- position: absolute;
- margin-left: -23px;
- margin-top: 11px;
- height: 0px;
- width: 0px;
- border-image: none;
- border: 10px solid transparent;
- border-right: 13px solid #ddd;
- }
-
- .attribution-comment {
- padding: 10px 10px 0px 10px;
- /*border: 1px solid #ccc;
- border-top: 0px;*/
- }
-
- .ticket-simple-event {
- padding: 5px 0px;
- }
-
- .status-display {
- text-align: center;
- font-weight: bold;
- }
-
- .status-change {
- font-size: 1.0em;
- text-shadow: none;
- padding: 5px 10px !important;
- font-weight: bold;
- display: inline-block;
- text-align: center;
- width: 50px;
- margin-right: 5px !important;
- }
-
- .submit-info {
- margin-bottom: 0px;
- border-radius: 0px;
- }
-
- .merge-panel {
- padding: 5px 7px;
- background-color: #fbfbfb;
- color: #444
- }
-
- .merge-panel p.step {
- margin: 10px 0px 5px;
- }
-
- .gitcommand {
- margin-top: 5px;
- border: 1px solid #ccc;
- background-color: #333 !important;
- color: #ccc;
- border-radius: 3px;
- padding: 5px;
- margin-bottom: 5px;
- text-shadow: none;
- }
-
- a.commit {
- border: 1px solid #ccc;
- border-radius: 3px;
- background-color: #fbfbfb;
- padding: 2px 4px;
- line-heihgt:99%;
- font-size: 11px;
- text-transform: lowercase;
- }
-
- h1 small, h2 small, h3 small, h4 small, h5 small, h6 small {
- color: #888;
- }
-
- .age0, .age1, .age2, .age3, .age4 {
- font-size: 12px;
- }
-
- /* age0: age < 2 hours */
- .age0 {
- font-style: italic;
- color: #008000;
- font-weight: bold;
- }
-
- /* age1: 2 hours <= age < 2 days */
- .age1 {
- font-style: italic;
- color: #0000ff;
- font-weight: bold;
- }
-
- /* age2: 2 days < age <= 7 days */
- .age2 {
- font-style: italic;
- color: #2b60de;
- }
-
- /* age3: 7 days < age <= 30 days */
- .age3 {
- color: #800080;
- }
-
- /* age4: > 30 days */
- .age4 {
- }
-
- /* Ensure that hovered ages are white */
- tr.light:hover .age0,
- tr.light:hover .age1,
- tr.light:hover .age2,
- tr.light:hover .age3,
- tr.light:hover .age4,
- tr.dark:hover .age0,
- tr.dark:hover .age1,
- tr.dark:hover .age2,
- tr.dark:hover .age3,
- tr.dark:hover .age4 {
- color: #ffffff !important;
- }
-
- a.list {
- text-decoration: none;
- color: inherit;
- }
-
- a.list-strikethrough {
- text-decoration: line-through;
- color: inherit;
- }
-
- a.list.subject {
- font-weight: bold;
- }
-
- a.list.name {
- font-weight: bold;
- }
-
- a.list:hover {
- text-decoration: underline;
- color: #880000;
- }
-
- span.empty {
- font-size: 0.9em;
- font-style: italic;
- padding-left:10px;
- color: #008000;
- }
-
- span.highlight {
- background-color: rgb(255, 255, 100);
- color: black;
- padding: 0px 2px;
- }
-
- span.link {
- color: #888;
- }
-
- span.link, span.link a {
- font-family: sans-serif;
- font-size: 11px;
- }
-
- span.link em, div.link span em {
- font-style: normal;
- font-family: sans-serif;
- font-size: 11px;
- }
-
- span.activitySwatch {
- border-radius: 3px;
- padding: 1px 4px 2px 4px;
- color: #ffffff;
- vertical-align: center;
- }
-
- span.activitySwatch a {
- color: inherit;
- }
-
- span.repositorySwatch {
- padding: 1px 1px 2px 1px;
- color: #ffffff;
- vertical-align: center;
- }
-
- span.repositorySwatch a {
- color: inherit;
- }
-
- img.inlineIcon {
- padding-left: 1px;
- padding-right: 1px;
- }
-
- img.overview {
- float:right;
- border:1px solid #CCCCCC;
- }
-
- img.gravatar {
- background-color: #ffffff;
- /*border: 1px solid #ddd;*/
- border-radius: 5px;
- padding: 2px;
- }
-
- img.gravatar-round {
- background-color: #ffffff;
- border: 1px solid #ccc;
- border-radius: 100%;
- }
-
- img.navbarGravatar {
- border: 1px solid #fff;
- }
-
- div.searchResult {
- padding: 10px 5px 10px 5px;
- }
-
- div.searchResult .summary {
- font-weight: bold;
- }
-
- div.searchResult .branch {
- color: #008000;
- }
-
- div.searchResult .author {
- font-style: italic !important;
- }
-
- div.searchResult .date {
- color:#999;
- }
-
- div.searchResult .body {
- padding-left:20px;
- }
-
- div.searchResult .fragment {
- padding: 7px 0;
- }
-
- div.searchResult .highlight {
- background-color: #ccff66;
- padding: 0 2px;
- }
-
- div.searchResult .ellipses {
- padding-left:25px;
- color: #aaa;
- }
-
- div.searchResult pre {
- margin: 1px 0px;
- border: 0px;
- }
-
- div.searchResult .text {
- border-left: 2px solid #ccc;
- border-radius: 0px;
-
- padding: 0 0 0 15px;
- }
-
- div.searchResult ol {
- margin-bottom: 0px !important;
- }
-
- div.header, div.commitHeader, table.repositories th {
- background-color: #fbfbfb;
- }
-
- div.header {
- padding: 3px;
- border: 1px solid #ddd;
- border-bottom: 0;
- font-weight: bold;
- font-family: Helvetica,arial,freesans,clean,sans-serif;
- }
-
- div.diffHeader {
- /* CSS trick to workaround #link topOfWindow offset problem */
- border-top: 65px solid transparent;
- margin-top: -65px;
- -webkit-background-clip: padding-box;
- -moz-background-clip: padding;
- background-clip: padding-box;
- }
-
- div.commitHeader {
- margin:0 0 2px;
- padding:7px 14px;
- border:1px solid #ddd;
- }
-
- div.header a, div.commitHeader a {
- color: black;
- text-decoration: none;
- font-weight: bold;
- }
-
- div.header a:hover, div.commitHeader a:hover {
- text-decoration: underline;
- }
-
- div.page_nav2 {
- padding: 5px 10px;
- margin: -10px 0px 10px;
- border-left: 1px solid #ccc;
- border-right: 1px solid #ccc;
- border-bottom: 1px solid #ccc;
- border-radius: 0px 0px 3px 3px;
- background-color: #ECF1F4;
- color: #666;
- text-align: left;
- }
-
- div.page_nav2 a {
- color: #002060;
- }
-
- div.admin_nav {
- border-bottom: 0px;
- text-align: right;
- padding: 5px 5px 5px 2px;
- }
-
- div.admin_nav a {
- text-decoration: none;
- }
-
- div.admin_nav a:hover {
- text-decoration: underline;
- }
-
- span.search {
- height: 40px;
- padding-top:2px;
- }
-
- span.search input {
- -webkit-border-radius:0;-moz-border-radius:0x;border-radius:0;
- vertical-align: top;
- background: url(search-icon.png) no-repeat 4px center;
- background-color: transparent;
- border: 1px solid transparent;
- outline: none;
- padding: 2px 2px 2px 22px;
- text-shadow: none;
- margin: 0px;
-
- color: #ddd;
- }
-
- span.search input:hover, span.search input:focus {
- background-color: transparent;
- border: 1px solid transparent;
- padding: 2px 2px 2px 22px;
- box-shadow: none;
- color: #ddd;
- border-bottom: 1px solid #ff9900;
- }
-
- span.search input:focus {
- color: white;
- }
-
- /* div.search input:focused { */
- /* background-color: transparent; */
- /* border: 1px solid transparent; */
- /* padding: 2px 2px 2px 22px; */
- /* text-shadow: none; */
- /* } */
-
- span.login input:focus {
- background-color: rgba(255, 255, 255, 0.6);
- text-shadow: none;
- color: white;
- }
-
- .commit_message {
- padding: 8px;
- }
-
- .topborder {
- border: solid #ddd;
- border-width: 1px 0px 0px;
- border-radius: 0px;
- }
-
- div.bug_open, span.bug_open {
- padding: 2px;
- background-color: #803333;
- color: white;
- text-align: center;
- }
-
- div.bug_resolved, span.bug_resolved {
- padding: 2px;
- background-color: #408040;
- color: white;
- text-align: center;
- }
-
- div.bug_invalid, span.bug_invalid {
- padding: 2px;
- background-color: gray;
- text-align: center;
- }
-
- div.bug_hold, span.bug_hold {
- padding: 2px;
- background-color: orange;
- text-align: center;
- }
-
- div.diff {
- font-family: monospace;
- overflow: auto;
- }
-
- div.diff.header {
- -moz-border-bottom-colors: none;
- -moz-border-image: none;
- -moz-border-left-colors: none;
- -moz-border-right-colors: none;
- -moz-border-top-colors: none;
- background-color: #EDECE6;
- border-color: #D9D8D1;
- border-style: solid;
- border-width: 1px;
- font-weight: bold;
- margin-top: 10px;
- padding: 4px 0 2px;
- }
-
- div.diff.extended_header {
- background-color: #F6F5EE;
- padding: 2px 0;
- font-family: inherit;
- }
-
- div.diff table {
- border: 1px solid #ddd;
- }
-
- span.diff.add {
- color: #008800;
- font-family: inherit;
- }
-
- span.diff.remove {
- color: #FFDDDD;
- font-family: inherit;
- }
-
- span.diff.unchanged {
- color: inherit;
- font-family: inherit;
- }
-
- span.diff.hunk_info {
- background-color: #FFEEFF;
- color: #990099;
- font-family: inherit;
- }
-
- span.diff.hunk_section {
- color: #AA22AA;
- font-family: inherit;
- }
-
- .diff-cell {
- margin: 0px;
- padding: 0 2px;
- border: 0;
- border-left: 1px solid #bbb;
- }
-
- .add2 {
- background-color: #DDFFDD;
- }
-
- .remove2 {
- background-color: #FFDDDD;
- }
-
- .context2 {
- background-color: #FEFEFE;
- }
-
- .trailingws-add {
- background-color: #99FF99;
- }
-
- .trailingws-sub {
- background-color: #FF9999;
- }
-
- div.diff > table {
- border-radius: 0;
- border-right: 1px solid #bbb;
- border-bottom: 1px solid #bbb;
- width: 100%;
- }
-
- .diff-line {
- background-color: #fbfbfb;
- text-align: center;
- color: #999;
- padding-left: 2px;
- padding-right: 2px;
- width: 3em; /* Font-size relative! */
- min-width: 3em;
- }
-
- .diff-line:before {
- content: attr(data-lineno);
- }
-
- .diff-state {
- background-color: #fbfbfb;
- text-align: center;
- color: #999;
- padding-left: 2px;
- padding-right: 2px;
- width: 0.5em; /* Font-size relative! */
- }
-
- .diff-state-add:before {
- color: green;
- font-weight: bold;
- content: '+';
- }
-
- .diff-state-sub:before {
- color: red;
- font-weight: bold;
- content: '-';
- }
-
- .hunk_header {
- background-color: #dAe2e5 !important;
- border-left: 1px solid #bbb;
- border-top: 1px solid #bac2c5;
- border-bottom: 1px solid #bac2c5;
- color: #555;
- }
-
- /* Image diffs. */
-
- /* Note: can't use gradients; IE < 10 doesn't support them. Use pre-created pngs with transparency instead. */
-
- /* Set on body during mouse tracking. */
- .no-select {
- -webkit-touch-callout:none;
- -webkit-user-select:none;
- -khtml-user-select:none;
- -moz-user-select:none;
- -ms-user-select:none;
- user-select:none;
- }
-
- div.imgdiff-container {
- padding: 10px;
- background: #EEE;
- }
-
- div.imgdiff {
- margin: 10px 20px;
- position:relative;
- display: inline-block;
- /* Checkerboard background to reveal transparency. */
- background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsTAAALEwEAmpwYAAAAK0lEQVQoz2O8e/cuAzagpKSEVZyJgUQwqoEYwPj//3+sEvfu3RsNJfppAACQZwizxs5QrAAAAABJRU5ErkJggg==);
- background-repeat: repeat;
- /* Same with CSS:
- background-color: white;
- background-image: linear-gradient(45deg, #DDD 25%, transparent 25%, transparent 75%, #DDD 75%, #DDD), linear-gradient(45deg, #DDD 25%, transparent 25%, transparent 75%, #DDD 75%, #DDD);
- background-size:16px 16px;
- background-position:0 0, 8px 8px;
- */
- }
-
- div.imgdiff-left {
- position: absolute;
- top: 0;
- bottom: 0;
- left: 0;
- width: 0;
- max-width: 100%;
- overflow: hidden;
- }
-
- img.imgdiff {
- user-select: none;
- border: 1px solid #0F0;
- }
- img.imgdiff-old {
- user-select: none;
- border: 1px solid #F00;
- }
-
- .imgdiff-opa-container {
- display: inline-block;
- width: 200px;
- height: 4px;
- margin: 12px 35px 6px 35px;
- padding: 0;
- position: relative;
- border: 1px solid #888;
- background-color: #DDD;
- }
-
- .imgdiff-opa-container:before {
- content: '';
- position: absolute;
- left: -20px;
- top: -4px;
- width : 12px;
- height: 12px;
- background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAwAAAAMCAYAAABWdVznAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA7klEQVQoz13STUrDMRAF8N+02fQDhCpqNyJIvUEXXfYCXtlFsZeQLpRCpYJ01RakxM38IRgIQyZv3rx5SchVaw1c4xm36OEb7/jqcJHgPuZYYopx3h2xwwrriPgtyTzHCx5xg1ESnvJ8lR1fS8pYJvgBEwyywwlD9LGotX6W1DxNpknutkPgnGSzkgOOEzRoogY8zPx9L7VFa0Ku//lAlLTumO1PjYxuhnMT9yV93uUMw2Q+NwU/OGCL95KPskrr+o3mruCAD7xhU1LjOpkX6caoGXib4HVEXKLWKiK67/GEGe6SYJ+SNxFxqbX2/gBxKkhxx1tQIAAAAABJRU5ErkJggg==);
- /* With CSS: background-image: radial-gradient(6px at 50% 50%, rgba(255, 255, 255, 255) 50%, rgba(255, 255, 255, 0) 6px); */
- }
-
- .imgdiff-opa-container:after {
- content: '';
- position: absolute;
- right: -20px;
- top: -4px;
- width : 12px;
- height: 12px;
- background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAwAAAAMCAYAAABWdVznAAAACXBIWXMAAAsTAAALEwEAmpwYAAABlklEQVQoz02Rr45TYRTE5/z7ynebYNBIFFuLXV2FQRIgWcUDkN3bBNnbR0CQJvsGGLCbIEFgSCrgGXCw7b3fOT2ILQm/ZJIRI2YyhBObzaZm5kVmvszMs8wkJtoR0ZZUr/vLyz/DMBCdwg+PcfzUvC3cHRGBTICZUYpBVb+KyPO+73/SZrOpEccv03hYHMbRp9bk6EEJQITTzFqttZjZ59ls9kwz88K9LQ7j6IfDXsdxgrcGEEFEqJRSAAQzn7fWXmtmvnJ3tNZkHCfc3t5iahOQgJWCBKCq1FqDiDzVzHwcEYgIcndMU8N+v0dmogNQzODufLcrzxiZhAQyEwBASGSedPL/wyDaMTNEJEUEpRi6rkPXdShWoKoQkWBmENGOmWhrxWBmrZSCe7ViPp9jPp+j1opSSpoZmxmY+YOS6rVmvqi1PgEQqkruzgAgImFmXGslVb1h5u2/4x65+/uIOG+tISLu+jLDzKCqN6r6pu/7bzIMA61Wq1/L5fIjgN8ict/MHphZmNl3VX1nJm+vrvof6/Xa/gJuQtCzTqj1dQAAAABJRU5ErkJggg==);
- /* With CSS: background-image: radial-gradient(6px at 50% 50%, #888, #888 1px, transparent 6px); */
- }
-
- .imgdiff-opa-slider {
- position:absolute;
- top : 0;
- left: -5px;
- bottom: 0;
- right: -5px;
- text-align: left;
- }
-
- .imgdiff-opa-handle {
- display: inline-block;
- width: 10px;
- height: 10px;
- position: absolute;
- top: -3px;
- background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAACXBIWXMAAAsTAAALEwEAmpwYAAABMklEQVQY022OsU7CUBRA723fpTS0NcVBJuOoQUed0MSJhOiP0IHK6g84ShoM/2HE1TjZxeCA0UF3RW2tLQ73mesgLuiZT3IOwoww7FSLYrrDzHUAMInUbblsX0RR9NJsNgEBAIIg2EjT9DDP8y2ttSsiqEhlTsW58TzvaDAYxBiGB9XJ5PkkSZJdZvZFRAEAIKImUm+et3BVqy11VFHkjTzPN2cS/a6ICDHrxWlR1N+zjz2DmddnOQVziIjJWnuaedUAAENEEP4iPweIImIYRDQmogwR9T+SVkplpVLpzrBt+9KpVEaK6BUReU6a2LY9dl33zIzj+LOx3XgUkRUQsADwSylzalnWk+M4I9/3o36/f42t/RYMT4fQ7XaX0zRpMes1ADAU0b3nuee9495DO2ib37s7ktpA7ddzAAAAAElFTkSuQmCC);
- /* With CSS: background-image: radial-gradient(5px at 50% 50%, #444, #888, transparent 5px); */
- }
-
- .imgdiff-ovr-slider {
- display: inline-block;
- margin: 0;
- padding: 0;
- position: relative;
- text-align: left;
- }
-
- .imgdiff-ovr-handle {
- display: inline-block;
- width : 1px;
- height: 100%;
- top: 0px;
- background-color: #444;
- border-right: 1px solid #FFF;
- }
-
- .imgdiff-ovr-handle:before {
- content: '';
- position: absolute;
- right: -4px;
- bottom: -5px;
- width : 10px;
- height: 10px;
- background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAACXBIWXMAAAsTAAALEwEAmpwYAAABMklEQVQY022OsU7CUBRA723fpTS0NcVBJuOoQUed0MSJhOiP0IHK6g84ShoM/2HE1TjZxeCA0UF3RW2tLQ73mesgLuiZT3IOwoww7FSLYrrDzHUAMInUbblsX0RR9NJsNgEBAIIg2EjT9DDP8y2ttSsiqEhlTsW58TzvaDAYxBiGB9XJ5PkkSZJdZvZFRAEAIKImUm+et3BVqy11VFHkjTzPN2cS/a6ICDHrxWlR1N+zjz2DmddnOQVziIjJWnuaedUAAENEEP4iPweIImIYRDQmogwR9T+SVkplpVLpzrBt+9KpVEaK6BUReU6a2LY9dl33zIzj+LOx3XgUkRUQsADwSylzalnWk+M4I9/3o36/f42t/RYMT4fQ7XaX0zRpMes1ADAU0b3nuee9495DO2ib37s7ktpA7ddzAAAAAElFTkSuQmCC);
- /* With CSS: background-image: radial-gradient(5px at 50% 50%, #444, #888, transparent 5px); */
- }
-
- .imgdiff-ovr-handle:after {
- content: '';
- position: absolute;
- right: -4px;
- top: -5px;
- width : 10px;
- height: 10px;
- background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAACXBIWXMAAAsTAAALEwEAmpwYAAABMklEQVQY022OsU7CUBRA723fpTS0NcVBJuOoQUed0MSJhOiP0IHK6g84ShoM/2HE1TjZxeCA0UF3RW2tLQ73mesgLuiZT3IOwoww7FSLYrrDzHUAMInUbblsX0RR9NJsNgEBAIIg2EjT9DDP8y2ttSsiqEhlTsW58TzvaDAYxBiGB9XJ5PkkSZJdZvZFRAEAIKImUm+et3BVqy11VFHkjTzPN2cS/a6ICDHrxWlR1N+zjz2DmddnOQVziIjJWnuaedUAAENEEP4iPweIImIYRDQmogwR9T+SVkplpVLpzrBt+9KpVEaK6BUReU6a2LY9dl33zIzj+LOx3XgUkRUQsADwSylzalnWk+M4I9/3o36/f42t/RYMT4fQ7XaX0zRpMes1ADAU0b3nuee9495DO2ib37s7ktpA7ddzAAAAAElFTkSuQmCC);
- /* With CSS: background-image: radial-gradient(5px at 50% 50%, #444, #888, transparent 5px); */
- }
-
- .imgdiff-link {
- margin: 0px 4px;
- text-decoration: none;
- border: none;
- }
-
- .imgdiff-link > img {
- border: 1px solid transparent; /* Avoid jumping when we change the border */
- width: 20px;
- height: 20px;
- margin-bottom: 10px;
- }
-
- /* End image diffs */
-
- td.changeType {
- width: 15px;
- }
-
- span.addition, span.modification, span.deletion, span.rename {
- border: 1px solid #888;
- float: left;
- height: 0.8em;
- margin: 0.2em 0.5em 0 0;
- overflow: hidden;
- width: 0.8em;
- }
-
- span.addition {
- background-color: #ccffcc;
- }
-
- span.modification {
- background-color: #ffdd88;
- }
-
- span.deletion {
- background-color: #f8bbbb;
- }
-
- span.rename {
- background-color: #cAc2f5;
- }
-
- div.commitLegend {
- float: right;
- padding: 0.4em 0.4em 0.2em 0.4em;
- vertical-align:top;
- margin: 0px;
- }
-
- div.commitLegend span {
- font-size: 0.9em;
- vertical-align: top;
- }
-
- div.references {
- float: right;
- text-align: right;
- }
-
- table.plain, table.summary, table.ticket {
- width: 0 !important;
- border: 0;
- }
-
- table.plain th, table.plain td, table.summary th, table.summary td {
- white-space: nowrap;
- padding: 1px 3px;
- border: 0;
- }
-
- table.ticket th, table.ticket td {
- padding: 1px 3px;
- border: 0;
- }
-
- table.summary {
- margin: 0px;
- }
-
- table.summary th, table.ticket th {
- color: #999;
- padding-right: 10px;
- text-align: right;
- font-weight: normal;
- }
-
- table.pretty {
- border:1px solid #ddd;
- border-radius: 0 0 3px 3px;
- width: 100%;
- }
-
- table.pretty td.icon {
- padding: 0px 0px 0px 2px;
- width: 18px;
- vertical-align: middle;
- }
-
- table.pretty td.icon img {
- vertical-align: middle;
- }
-
- table.pretty td {
- padding: 2px 4px;
- border-left: 0;
- }
-
- table.pretty td.message {
- padding: 0px;
- }
-
- table.pretty table.nestedTable {
- width: 100%;
- margin-left: 4px !important;
- margin-bottom: 0px !important;
- }
-
- table.pretty td.graph {
- border-right: 1px solid #ddd;
- border-bottom: 1px solid #ddd;
- padding: 0px;
- /*width: 1px;*/
- }
-
- table.pretty tr.commit {
- /* must match branch graph servlet row height definition */
- height: 24px;
- }
-
- @media (min-width: 979px) {
- td.ellipsize {
- text-overflow: ellipsis;
- overflow: hidden;
- white-space: nowrap;
- }
- }
-
- @media (max-width: 979px) {
- td.ellipsize {
- text-overflow: inherit;
- overflow: visible;
- white-space: wrap;
- }
- }
-
- td.sha256 {
- max-width: 20em;
- overflow: hidden;
- text-overflow: ellipsis;
- }
-
- table.comments td {
- padding: 4px;
- line-height: 17px;
- }
-
- table.projectlist {
- margin-top: 10px;
- }
-
- table.repositories {
- border:1px solid #ddd;
- border-spacing: 0px;
- width: 100%;
- }
-
- table.repositories th {
- padding: 4px;
- border:0;
- }
-
- table.repositories th.right {
- border-right: 1px solid #ddd;
- }
-
- table.repositories td {
- padding: 2px;
- border-left: 0;
- }
-
- table.repositories td.rightAlign {
- text-align: right;
- border-right: 1px solid #ddd;
- }
-
- table.repositories td.icon img {
- vertical-align: top;
- }
-
- table.repositories tr.group {
- background-color: #ccc;
- border-left: 1px solid #ccc;
- border-right: 1px solid #ccc;
- }
-
- table.repositories tr.group td {
- font-weight: bold;
- color: black;
- background-color: #ddd;
- padding-left: 5px;
- border-top: 1px solid #aaa;
- border-bottom: 1px solid #aaa;
- }
-
- table.repositories tr.group td a {
- color: black;
- }
-
- table.palette { border:0; width: 0 !important; }
- table.palette td.header {
- font-weight: bold;
- background-color: #ffffff !important;
- padding-top: 0px !important;
- margin-bottom: 0 !important;
- border: 0 !important;
- border-radius: 0 !important;
- line-height: 1em;
- }
- table.palette td.pane {
- padding: 0px;
- width: 250px !important;
- }
-
- table.palette td.pane select {
- width: 250px !important;
- }
-
- table.gitnotes {
- border: 0;
- }
- table.gitnotes td {
- border-top: 1px solid #ddd;
- padding-top: 3px;
- vertical-align:top;
- }
-
- table.gitnotes table {
- border: none;
- }
-
- table.gitnotes td table td {
- border: none;
- padding: 0px;
- }
-
- table.gitnotes td.info {
- padding-right: 10px;
- }
-
- table.gitnotes td.message {
- width: 65%;
- border-left: 1px solid #ddd;
- padding-left: 10px;
- }
-
- table.annotated {
- width: 100%;
- border:1px solid #ddd;
- }
-
- table.annotated tr.even {
- background-color: white;
- }
-
- table.annotated tr.odd {
- background-color: #f5f5f5;
- }
-
- table.annotated td {
- padding: 0px;
- border: 0;
- }
-
- table.annotated td.lineCommit {
- padding-left: 5px;
- padding-right: 5px;
- }
-
- table.annotated td.lineNumber {
- border-right: 1px solid #ddd;
- border-left: 1px solid #ddd;
- padding-left: 5px;
- padding-right: 5px;
- text-align: right;
- }
-
- table.annotated td.lineContent {
- padding-left: 5px;
- font: monospace;
- }
-
- table.activity {
- width: 100%;
- margin-top: 10px;
- }
-
- table.activity td {
- padding-top:7px;
- padding-bottom:7px;
- }
-
- tr th a { background-position: right; padding-right: 15px; background-repeat:no-repeat; }
- tr th.wicket_orderDown a {background-image: url(arrow_down.png); }
- tr th.wicket_orderUp a { background-image: url(arrow_up.png); }
- tr th.wicket_orderNone a { background-image: url(arrow_off.png); }
-
- tr.light {
- background-color: #ffffff;
- }
-
- tr.dark {
- background-color: #f6f6f6;
- }
-
- /* currently both use the same, but it can change */
- tr.light:hover,
- tr.dark:hover {
- background-color: #002060;
- color: white;
- }
-
- tr.light:hover a,
- tr.dark:hover a {
- color: white;
- }
-
- .merge {
- opacity: 0.5;
- }
-
- .merge:hover {
- opacity: 1;
- }
-
- td.author {
- font-style: italic !important;
- white-space: nowrap;
- }
-
- td.date {
- /*font-style: italic !important;*/
- white-space: nowrap;
- }
-
- span.sha1, span.sha1 a, span.sha1 a span, .commit_message, span.shortsha1, td.sha1, td.sha256 {
- font-family: consolas, monospace;
- font-size: 13px;
- }
-
- span.shortsha1 {
- font-size: 12px;
- }
-
- td.mode {
- text-align: right;
- font-family: monospace;
- width: 8em;
- padding-right:15px;
- }
-
- td.filestore {
- text-align: right;
- width:1em;
- padding-right:15px;
- }
-
- td.size {
- text-align: right;
- width: 8em;
- padding-right:15px;
- }
-
- td.rightAlign {
- text-align: right;
- }
-
- td.treeLinks {
- text-align: right;
- width: 13em;
- }
-
- span.help-inline {
- color: #777;
- }
-
- span.metricsTitle {
- font-size: 2em;
- }
-
- .tagRef, .headRef, .localBranch, .remoteBranch, .otherRef, .pullRef {
- padding: 0px 3px;
- margin-right:2px;
- font-family: sans-serif;
- font-size: 9px;
- font-weight: normal;
- border: 1px solid;
- color: black;
- }
-
- .tagRef a, .headRef a, .localBranch a, .remoteBranch a, .otherRef a, .pullRef a {
- font-size: 9px;
- text-decoration: none;
- color: black !important;
- }
-
- .tagRef a:hover, .headRef a:hover, .localBranch a:hover, .remoteBranch a:hover, .otherRef a:hover, .pullRef a:hover {
- color: black !important;
- text-decoration: underline;
- }
-
- .otherRef {
- background-color: #b0e0f0;
- border-color: #80aaaa;
- }
-
- .pullRef {
- background-color: rgb(255, 221, 136);
- border-color: rgb(136, 136, 136);
- }
-
- .remoteBranch {
- background-color: #cAc2f5;
- border-color: #6c6cbf;
- }
-
- .tagRef {
- background-color: #ffffaa;
- border-color: #ffcc00;
- }
-
- .headRef {
- background-color: #ffaaff;
- border-color: #ff00ee;
- }
-
- .localBranch {
- background-color: #ccffcc;
- border-color: #00cc33;
- }
-
- table .palette td.buttons button {
- -webkit-border-radius:3px;-moz-border-radius:3px;border-radius:3px;
- border: 1px solid #ccc !important;
- padding: 10px;
- margin-bottom: 10px;
- }
-
- table .palette td.buttons button:hover {
- border: 1px solid #0069D6 !important;
- }
-
- table .palette td.buttons button:active {
- border: 1px solid orange !important;
- }
-
- .feedbackPanelERROR, .feedbackPanelINFO {
- list-style: none;
- line-height: 35px;
- }
-
- .feedbackPanelINFO span, .feedbackPanelERROR span {
- position:relative;padding:7px 15px;margin-top:5px;margin-bottom:5px;color:#404040;background-color:#eedc94;background-repeat:repeat-x;background-image:-khtml-gradient(linear, left top, left bottom, from(#fceec1), to(#eedc94));background-image:-moz-linear-gradient(top, #fceec1, #eedc94);background-image:-ms-linear-gradient(top, #fceec1, #eedc94);background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #fceec1), color-stop(100%, #eedc94));background-image:-webkit-linear-gradient(top, #fceec1, #eedc94);background-image:-o-linear-gradient(top, #fceec1, #eedc94);background-image:linear-gradient(top, #fceec1, #eedc94);filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#fceec1', endColorstr='#eedc94', GradientType=0);text-shadow:0 -1px 0 rgba(0, 0, 0, 0.25);border-color:#eedc94 #eedc94 #e4c652;border-color:rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.25);text-shadow:0 1px 0 rgba(255, 255, 255, 0.5);border-width:1px;border-style:solid;-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px;-webkit-box-shadow:inset 0 1px 0 rgba(255, 255, 255, 0.25);-moz-box-shadow:inset 0 1px 0 rgba(255, 255, 255, 0.25);box-shadow:inset 0 1px 0 rgba(255, 255, 255, 0.25);
- }
-
- .feedbackPanelERROR span {
- color: #ffffff;
- background-color:#c43c35;background-repeat:repeat-x;background-image:-khtml-gradient(linear, left top, left bottom, from(#ee5f5b), to(#c43c35));background-image:-moz-linear-gradient(top, #ee5f5b, #c43c35);background-image:-ms-linear-gradient(top, #ee5f5b, #c43c35);background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #ee5f5b), color-stop(100%, #c43c35));background-image:-webkit-linear-gradient(top, #ee5f5b, #c43c35);background-image:-o-linear-gradient(top, #ee5f5b, #c43c35);background-image:linear-gradient(top, #ee5f5b, #c43c35);filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#ee5f5b', endColorstr='#c43c35', GradientType=0);text-shadow:0 -1px 0 rgba(0, 0, 0, 0.25);border-color:#c43c35 #c43c35 #882a25;border-color:rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.25);
- }
-
- /* google-code-prettify line numbers */
- li.L0,
- li.L1,
- li.L2,
- li.L3,
- li.L4,
- li.L5,
- li.L6,
- li.L7,
- li.L8,
- li.L9 { color: #888; border-left: 1px solid #ccc; padding-left:5px; list-style-type: decimal !important; }
-
- /* Alternate shading for lines */
- li.L1,
- li.L3,
- li.L5,
- li.L7,
- li.L9 { background: #fafafa !important; }
-
- div.docs ul.nav {
- margin-bottom: 0px !important;
- }
-
- div.docs div.docnav {
- display: inline-block;
- padding: 6px 5px 6px 5px;
- border-left: 1px solid #ccc;
- border-right: 1px solid #ccc;
- border-bottom: 1px solid #ccc;
- border-radius: 0px 0px 3px 3px;
- background-color: #ECF1F4;
- color: #666;
- text-align: left;
- margin-top: -10px;
- }
-
- div.docs .content {
- margin-top: 10px;
- }
-
- div.docs div.markdown {
- margin-top: 10px;
- }
-
- div.markdown {
- line-height: 1.4;
- }
-
- div.markdown h1 {
- padding: 0px 0px 4px;
- border-bottom: 1px solid rgb(221, 221, 221);
- margin: 4px 0px 8px;
- }
-
- div.markdown h2 {
- padding: 4px 0px;
- border-bottom: 1px solid rgb(238, 238, 238);
- margin: 4px 0px 8px;
- }
-
- div.markdown h3 {
- padding: 8px 0px 4px;
- }
-
- div.markdown li {
- line-height: 1.4;
- }
-
- div.markdown pre {
- background-color: rgb(250, 250, 250);
- border: 1px solid rgb(221, 221, 221);
- border-radius: 4px 4px 4px 4px;
- display: block;
- font-size: 12px;
- line-height: 18px;
- margin: 9px 0;
- padding: 8.5px;
- white-space: pre-wrap;
- }
-
- div.markdown pre code {
- background-color: inherit;
- border: none;
- padding: 0;
- }
-
- div.markdown code {
- background-color: rgb(250, 250, 250);
- border: 1px solid rgb(221, 221, 221);
- border-radius: 3px;
- padding: 0 0.4em;
- }
-
- div.markdown table {
- max-width: 100%;
- background-color: transparent;
- border-collapse: collapse;
- border-spacing: 0px;
- font-size: inherit;
- border-width: 0px 1px 1px 0px;
- border-style: solid solid solid none;
- border-color: rgb(221, 221, 221);
- border-image: none;
- border-collapse: separate;
- margin: 10px 0px 20px;
- }
-
- div.markdown table td, div.markdown table th {
- padding: 8px;
- line-height: 20px;
- text-align: left;
- vertical-align: top;
- border-top: 1px solid rgb(221, 221, 221);
- border-left: 1px solid rgb(221, 221, 221);
- }
-
- div.markdown table.text th, div.markdown table.text td {
- vertical-align: top;
- border-top: 1px solid #ccc;
- padding:5px;
- }
- .resolution {
- text-transform: uppercase;
- font-weight: bold !important;
- font-size: 11px;
- }
- .resolution-success, .resolution-success a {
- color: #14892c !important;
- }
- .resolution-success a:hover {
- color: white !important;
- }
- .resolution-error, .resolution-error a {
- color: #d04437 !important;
- }
- .resolution-error a:hover {
- color: white !important;
- }
- .resolution-complete, .resolution-complete a {
- color: #4a6785 !important
- }
- .resolution-complete a:hover {
- color: white !important;
- }
- .resolution-current, .resolution-current a {
- color: #594300 !important;
- }
- .resolution-current, .resolution-current a:hover {
- color: white;
- }
-
- /*! AUI Lozenge */
- .aui-lozenge {
- background: #ccc;
- border: 1px solid #ccc;
- border-radius: 3px;
- color: #333;
- display: inline-block;
- font-size: 11px;
- font-weight: bold;
- line-height: 99%; /* cross-browser compromise to make the line-height match the font-size */
- margin: 0;
- padding: 2px 5px;
- text-align: center;
- text-decoration: none;
- text-transform: uppercase;
- }
- .aui-lozenge.aui-lozenge-subtle {
- background-color: #fff;
- border-color: #ccc;
- color: #333;
- }
- .aui-lozenge-success {
- background-color: #14892c;
- border-color: #14892c;
- color: #fff;
- }
- .aui-lozenge-success.aui-lozenge-subtle {
- background-color: #fff;
- border-color: #b2d8b9;
- color: #14892c;
- }
- .aui-lozenge-error {
- background-color: #d04437;
- border-color: #d04437;
- color: #fff;
- }
- .aui-lozenge-error.aui-lozenge-subtle {
- background-color: #fff;
- border-color: #f8d3d1;
- color: #d04437;
- }
- .aui-lozenge-current {
- background-color: #ffd351;
- border-color: #ffd351;
- color: #594300;
- }
- .aui-lozenge-current.aui-lozenge-subtle {
- background-color: #fff;
- border-color: #ffe28c;
- color: #594300;
- }
- .aui-lozenge-complete {
- background-color: #4a6785;
- border-color: #4a6785;
- color: #fff;
- }
- .aui-lozenge-complete.aui-lozenge-subtle {
- background-color: #fff;
- border-color: #e4e8ed;
- color: #4a6785;
- }
- .aui-lozenge-moved {
- background-color: #815b3a;
- border-color: #815b3a;
- color: #fff;
- }
- .aui-lozenge-moved.aui-lozenge-subtle {
- background-color: #fff;
- border-color: #ece7e2;
- color: #815b3a;
- }
- .severity-catastrophic {
- color:#D51900;
- }
- .severity-catastrophic:after {
- font-family: Helvetica,arial,freesans,clean,sans-serif ;
- content: "●●●●●";
- font-weight:900;
- font-size:.45em;
- font-variant:small-caps;
- display:flex;
- white-space: pre;
- }
- .severity-critical {
- color:#D55900;
- }
- .severity-critical:after {
- font-family: Helvetica,arial,freesans,clean,sans-serif ;
- content: " ●●●●";
- font-weight:900;
- font-size:.45em;
- font-variant:small-caps;
- display:flex;
- white-space: pre;
- }
- .severity-serious {
- color:#E69F00;
- }
- .severity-serious:after {
- font-family: Helvetica,arial,freesans,clean,sans-serif ;
- content: " ●●●";
- font-weight:900;
- font-size:.45em;
- font-variant:small-caps;
- display:flex;
- white-space: pre;
- }
- .severity-minor {
- color:#009E73;
- }
- .severity-minor:after {
- font-family: Helvetica,arial,freesans,clean,sans-serif ;
- content: " ●●";
- font-weight:900;
- font-size:.45em;
- font-variant:small-caps;
- display:flex;
- white-space: pre;
- }
- .severity-negligible {
- color:#0072B2;
- }
- .severity-negligible:after {
- font-family: Helvetica,arial,freesans,clean,sans-serif ;
- content: " ●";
- font-weight:900;
- font-size:.45em;
- font-variant:small-caps;
- display:flex;
- white-space: pre;
- }
- .severity-unrated {
- }
- .priority-urgent {
- color:#D51900;
- }
- .priority-high {
- color:#D55900;
- }
- .priority-normal {
- }
- .priority-low {
- color:#0072B2;
- }
-
- .file-positive {
- color:#009E73;
- }
-
- .file-negative {
- color:#D51900;
- }
|
