* stable-2.11:
Set version to 2.11.11
Replace links to code.google.com/p/gerrit
Update issue tracker URL in documentation
Update issue tracker URL in POM files
Bump jsch to 0.54
Update jsch to 0.1.53
Bump Jsch to 1.52
Change-Id: Ie23ff4282f5b49a54f7043a4e932a4d18f2b5ef8
0.1.53 contains several bug fixes and new features
since 0.1.52.
http://www.jcraft.com/jsch/ChangeLog
Change-Id: I7a3ff5217ad38c925200a1ac9df096f616157350
According to the change log the new version fixed some bugs and added
some new features: [1].
[1] http://www.jcraft.com/jsch/ChangeLog
Change-Id: Iff40eec5da1906c85c4325bb2cd14f996d849d6d
As in Ifd9d768d, making flush a no-op is not sufficient to ensure
nothing gets written to the repo.
Bug: Issue 6965
Change-Id: If08e8184b484a0e7ba41fd3e11130d6fb26ed6c6
There were many changes in the topic predicate since the last time it
worked with regex but the first change that introduced this regression
is Ifdb12319. It changed the topic field from exact match to prefix which
broke the regex search.
Bug: Issue 5759
Change-Id: Ifa35083c5802c3cb980a58c035ff4f8efd9fac7b
RevWalk.isMergedInto takes the base as first argument and the tip as
the second argument to check if the base is merged into the tip. The
test didn't detect it because in the test the base is the same as the
tip.
Also add a regression test for this bug.
Change-Id: I43742aa4bd75ea64e729c1d3ecf40369002c7e55
This reverts commit 3fd92a4ac50e5ef49043858ab2576050634a3c2e.
The change was supposed to print the username in the queue for git over
http operations but the username printed is the one of the person doing
show-queue, not the one doing the git operation.
Change-Id: I2f45d526b684af9f3aa336879b310a165048382e
ProjectQoSFilter uses username as a part of task info. However,
AuthFilter which comes later than ProjectQoSFilter renders the
value of username. As a result, username never gets resolved when
using git with http.
The current patch set resolves the username only when it is used,
i.e., in the toString method, and saves the value for reusage.
Bug: Issue 5206
Change-Id: I280c95b242d599919eee3c7007c60a0047170166
A project can be visible to a user but not necessarily its parent. To
be consistent, a user with create-project permission should be able to
create a project with a parent that exists even if the parent is not
visible to the user.
Here is an example when this case is happening. On a Gerrit server where
All-projects is only visible to administrators and create-project
permission is granted to non-administrators, when a non-administrator
tries to create a project with All-Projects (which is the default when
parent is not specified) as its parent, it was failing before this
change with "Not found: All-Projects".
Change-Id: Id93370ab108f377f643b55efdf781dfd2c66f220
There was a test for the negative case, when user cannot create project
so add the positive case, when user is granted the global capability.
Change-Id: I8c23ae3c2a27cbe91f43f5ec8b92964cfcbc8873
So far, given no validation query was specified, a broken connection
could be returned from the connection pool and this caused a 500 error
when trying, for example, to read a change from the database.
Specify a default validation query that works for several of the DBMS
supported by Gerrit (H2, PostgreSQL, MySQL), and specific validation
queries for other supported databases (Apache Derby, DB2, Oracle).
Validation queries were verified for open source databases (H2, MySQL,
PostgreSQL and Derby).
Change-Id: Ia215288d70b11893b7d1403611e109a5a951f090
Commit a61b6eed5337049a7feb58ac935543624f107129 introduced a bug that
prevents mergeing of a branch that is not a change.
It marks the branch to be merged into as uninteresting whereas the
branch that gets merged is not, which causes Gerrit to think that it
is not allowed to merge it resulting in MISSING_DEPENDENCIES error.
In the case where the walk hits a commit that does not have canMergeFlag
and is not in the commits to be submitted, check if commit is already
merged.
Bug: Issue 4930
Change-Id: Ib4f95ebe336e381d6fcbf36867e84d927ac13eb1
The list-groups REST API call checked group visibility even for those
groups which are filtered out. In a system with 10-20K of groups
this can cause 30-60 seconds delay when checking if current user can
see a group.
Avoid unnecessary group visibility checks by moving it towards the end
of the loop. Therefore, group visibility is only checked for those
groups which are not filtered out.
Change-Id: Id5984049d0103fbbf656b704f672f01283844b64
The test for submitting whole topic on multiple branches was broken in
several ways:
- It was resetting the "dev" branch using the initial head of the default
test project, rather than that of the specifically created project.
- The base revision of the created "dev" branch was not specified, so it
was not clear where it was being created from.
- The call to the API to create the "dev" branch was done without using
the properly namespaced project name.
Fix all of these problems.
Also, when running the whole suite of tests under Java 7 some of them
failed, while the same tests passed when running individually. The root
cause of this is not yet known, but it would seem that the tests are
somehow interfering with each other.
Annotate the AbstractSubmit class with @Sandboxed so that each test is
run on a separate server instance. This makes the tests somewhat slower,
but makes sure they don't interfere with each other any more.
Change-Id: I2728106fce71d239b09572928b0f7489b96cdc64
There are some tests where it is especially hard to make sure that they
are not influenced by other tests in the same class. This includes all
indexer tests since some of them check the cardinality of a query result,
which might change as more entities are added by other tests.
This is a backport of the original change, adapted to work on stable-2.12.
Change-Id: I74b40b2e7f95894dd666dcd87d97fd29b2d67c51
When updating mergeTip in updateChanges mergeTip is not updated
between cherry-picks so all commits in Batch will be done on tip of
target branch, not stacked on each other.
Bug: Issue 4887
Change-Id: I59ce9f60eba08e44dd1e9a8ac1a9c953ed066570
Add an additional check that the remote log has the expected commits
after the submit.
Bug: Issue 4887
Change-Id: Ia39fd771d9e019f97670d6131022fcd3d8d2965d
Backport for stable-2.12 of:
Notice merged changes even if they appear on a different branch
Idcaec3f0db9e67b8a8390ddd73c0aca95a654b0b
Check for merge changes contains an optimization which is overeager: It
assumes that all changes that are reachable from any branch are not part
of the set of new changes being applied. This speeds up the walk to
determine the set of changes to be examined, but produces an incorrect
[too small] set.
This results in "internal error: change is new" errors when trying to
submit a change to one branch that is already part of another branch.
For RebaseIfNecessary:
Do not mark child of merge candidates as uninteresting
If a merge candidate is parent of one of the already accepted refs,
the merge candidate will disappear during the sorting in
RebaseSorter#sort if it's child is marked as uninteresting. Only mark
tip of target branch as uninteresting.
Bug: Issue 4158
Inspired-by: Stefan Beller <sbeller@google.com>
Change-Id: I483de5bdb2740bb1a7d3dcb71a15865574231647
The '-ms-user-select' css property doesn't support 'initial', so use
'text' instead.
Also add the 'user-select' css property for browsers that don't prefix
their css properties.
Bug: Issue 4647
Change-Id: Ife1ebcc8f4aadddb80de18515065c13339d54f64
The call to closeRepository() from the finally block on line 461
doubles up with the "normal" call on line 446, so we have to make sure
not to close() the repo twice.
This resulted in the counter for the repo to regularly reach exactly 0,
when all cached data are flushed, and we suffer a serious performance
hit. Once enough changes have been merged however (especially more than
the number of indexing threads that kick in immediately after a
successful merge to check for mergeability), the counter stays
consistently negative and performances return to normal.
Note that this has been fixed in 2.13 as a side-effect of 4b1e2a460.
Change-Id: I49181f0bff7b57d83bfad4ba225d1266ee545b35
Before this commit, the tasks name were printed like this:
com.google.gerrit.lucene.LuceneChangeIndex$QuerySource$1@77352d29
Now, the Lucene query is printed, example:
((status:new OR status:draft) owner:1000001)
Change-Id: I9a08a8eef08af5dba9b0948b9ae445a807fe8b87
What this config does is it either enables or disables lineWrapping,
disabling line wrapping can cause changes that have long lines to simply
be cut off.
With it enabled it will line wrap the text making it easer to read instead
of it being cutoff.
Gerrit 2.8.1 did lineWrapping so bringing this back. But it is set to the
default false so it is not enabled by default in Edit or Diff sections.
We should probaly set it as true in gerrit 2.13.
This also will partially fix bug
https://phabricator.wikimedia.org/T144565
which is filled downstream. Reason why this is partially fixed is because
the pref is not set to true by default and logged out users will still
see no line wrapping.
Bug: Issue 4292
Bug: Issue 2410
Change-Id: I8600778f1068c217e335755a3138e8cb64bc8b3e
If you don't have a big enough screen the options at the bottom get cut
off so it makes it very hard to change the options
Change-Id: I99ca18842b99a486589409f8c57d4ee901d0796a
Using AtomicBoolean is racy. It's actually safer to use static
initialization.
The problem being addressed in change I92a6c98d8 was fixed by making
the usage of OutgoingEmailValidator consistent in CreateEmail and
CreateAccount.
This partially reverts commit 3aaf8318936d08fbb2f4c5bdf4aaa475037d651a.
Change-Id: Ia10c74705a3e467c9f31896ac72ec231acb37635
The call to DomainValidator.updateTLDOverride may only be done before
the call to EmailValidator.getInstance otherwise it throws an exception.
Putting the DomainValidator.updateTLDOverride call inside a static
block doesn't seem to be safe enough. Protect it with an atomic boolean
insteed.
Also fix CreateEmail and CreateAccount to use OutgoingEmailValidator
instead of EmailValidator.getInstance directly. By directly using it we
don't necessarily set up the TLD override correctly before first use.
Bug: Issue 4521
Change-Id: I92a6c98d8ae188c08da7c0a077d67000dfdab4fd
Backport of I54296d62fd9206b2ed2bbcbd5bbcc941890206a3 to stable-2.12
Like searches, it is not safe to interrupt the IndexWriter. It also
reads from the NIOFSDirectory which closes file handles if the thread
is interrupted (such as by SSH command being Ctrl-C'd).
Although IndexWriter is thread safe it is essentially single threaded.
Each of these methods acquires a lock on entry, manipulates the index,
and releases the lock. There isn't a lot of value in allowing these to
be running on parallel threads borrowed from Gerrit.
Background (and serialize) all writes onto a single thread to prevent
an interrupt on the application thread from passing into Lucene code.
Change-Id: I2678e1a4c106c027b02fce47d0a570f59f6dde57
Once a change is written to the backing store (ReviewDb or NoteDb), it
should also be written into the secondary index, even if the user
tries to abort the current operation (e.g. presses Ctrl-C on a
running `git push`). Don't allow cancellation of a higher level
future to go down into the index update future.
This also better protects Lucene from seeing an interrupt while using
the secondary index and closing the NIOFSDirectory.
Change-Id: I8027a6226a5a1f7196506a0388a66d0568f67a5c
Since change I2c0f26bb4 it is not possible to change the username
after it has been set. Attempting to do so results in an exception.
This situation can occur for example if `ldap.accountSshUserName` is
set in the `gerrit.config` using `${userPrincipalName.localPart}` to
initialize the username from the user's email address. If the user's
email address changes after their first login, the username resolved
by `accountSshUserName` will change. Then on subsequent logins, when
AccountManager tries to change it to the new value, an exception is
thrown and the user is not able to log in.
Instead of attempting to change the username, log a warning.
Change-Id: Ie9d3501b2c386990c8439b3c7a9aae06cf51013b
The problem occurs when IndexConfig is created with the
default value, i.e., Integer.MAX_VALUE, and the start
value in the QueryOptions instance is greater than 0.
Bug: Issue 4006
Change-Id: Ib746a7941505a10e0c5a2b1d0a3ca79fca11de5f
Originally, the change clean up task abandons one change after
another in a list. As a result of potentially long list of changes
to abandon, a change could be updated by the user again after the
list is collected and before we reach it.
Double-check if the change still satisfies the abandon criterion
right before abandoning it.
Change-Id: I09f012d3f4ee1f96535e15523010d02b9a881123
