| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Instead of adding another setting and having to explain how the new one
and the existing `requireClientCertificates` setting are interdependent,
let's use the existing setting and add new values.
It is changed from a boolean to a string, with the values `required`,
`optional` and `disabled`. To keep backward compatibility with the old
values, the `true` value is mapped to `required` and the `false` value
is mapped to `optional`.
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The regular expression used for user mentions used to work
only inside sentences. Also, since it tested for whitespace, the
whitespace would get replaced, too, which would join lines together.
Instead the new regex uses boundary matchers to match against
word boundaires. As these are not capturing only the actual user
mention can be captured and is then replaced. Also, this way the
regex can ignore punctuation like in "@jim, look at this."
Since Gibtlit now requires Java 7 we can use named capture groups.
This makes the use of a centrally defined regular expression much
safer. The (admittedly only) group to capture the user name is named
"user" and can be referenced by this name. By using the name instead
of a group number, the regex could be changed without the code using
it breaking because the group number changed.
A simple test is added for user mentions, which unfortunately
has to deal with the full markdown replacement, too.
Fixes #985
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
Add the option to merge a ticket branch to the integration branch
only when it can be fast-forwarded, or
always with a merge commit, or
by fast-foward if possible, otherwise with a merge commit.
Adds a new property ticket.mergeType with the valid values
FAST_FOWARD_ONLY, MERGE_ALWAYS and MERGE_IF_NECESSARY.
Merging and canMerge were refactored to make use of a new
IntegrationStrategy class for each type of strategy.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
+ GitLFS client support
+ FilestoreModel now parses meta file
+ Read meta heading from cache if available
+ Authentication based on accept headers for browser view filestore login
+ PathModel & PathChangeModel now understands filestore items
+ Zip & Rar downloads contain include filestore items
+ Filestore servlet returns LFS JSON error only if accepted by client
+ DiffStat now knows repository to allow identification of filestore items
+ Filestore items identified and returned via view, raw & blob links on
blame, commitDiff, commit and Tree pages
|
|
|
|
|
|
|
| |
This was unused and causing provider lookup to fail in
AuthenticationManager.findProvider() by changing it out
from underneath. As a result, the supportXChanges methods
weren't being reported correctly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
+ Metadata maintained in append-only JSON file providing complete audit
history.
+ Filestore menu item
+ Lists filestore items
+ Current size and availability
+ Link to GitBlit Filestore help page (top right)
+ Hooks into existing repository permissions
+ Uses default repository path for out-of-box operation with Git-LFS
client
+ accessRestrictionFilter now has access to http method and auth header
+ Testing for servlet and manager
|
|
|
|
|
| |
+ use request instead of session to flag authentication status
and user, for external authentication types
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| | |
This is a quick return of the servlet3-style code which was reverted mid-December 2013. It is not completely tested, but a casual review was done and it's looks good. The next steps should be to restore `@Inject` annotations, simplify *DaggerModule* boilerplate, and run this on a JEE container with CDI - like JBoss AS 7.
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
details of the tags in the repository instead of the commits.
This uses a new 'ot' request parameter to indicate the object type of the content to return, which can be ither TAG or COMMIT.
If this is not provided, then COMMIT is assumed to maintain backwards compatability.
If tags are returned, then the paging parameters, 'l' and 'pg' are still supported, but searching options are currently ignored.
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add git-upload-pack and git-receive-pack commands.
Conflicts:
src/main/java/com/gitblit/manager/ServicesManager.java
src/main/java/com/gitblit/transport/ssh/CommandDispatcher.java
src/main/java/com/gitblit/transport/ssh/SshCommandFactory.java
Change-Id: I8c057b41f1dfad6d004e6aa91f96c8c673be9be2
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I0a3aced3b8e9887347888c85e469b74fc70931ad
|
|
|
|
| |
Change-Id: I3cd332a6509e434d901e1b262600f4c8ce57752b
|
|
|
|
| |
Change-Id: I336e005e02623fc5e11a4f8b4408bea5465a43fd
|
|
|
|
| |
Change-Id: I5f0f50f4ae7d332e9f724a2e6f074fa71f646035
|
|
|
|
| |
Change-Id: I9f91138b20219be6e3c4b28251487df262bff6cc
|
|
|
|
| |
Change-Id: Ie0b7d1e11d634577e943c8e4dbab080b0078f1b4
|
|
|
|
| |
Change-Id: I3460c9c0eeb32503d58325fd09793a0cd40aa2c4
|
| |
|
|
|
|
|
|
|
|
|
| |
The graph is generated server-side and therefore requires that the
commit table row height be fixed and match the row height of the
servlet. There will be layout misalignment if remotes refs are
displayed. Perhaps this can be improved in the future.
Change-Id: I39d0ffc7b1c3679976ce8c198c772ff86238f1a5
|
| |
|
|
|
|
|
|
|
| |
Add a new class, HtpasswdUserService, which performs authentication
against a text file created with the Apache 'htpasswd' program.
Added dependency on commons-codec:1.7
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|