qtqa/gerrit.git, branch v2.7-56-based

recognize 'Fixes' footer in commit-msg hook

2018-09-13T18:12:00+00:00

Change-Id: I211fe2ef5079c2391ec5cb7664e240c997203d8c
Reviewed-by: Sergio Ahumada 
Reviewed-by: Edward Welbourne

recognize Task-number footer

2016-03-02T19:32:48+00:00

Change-Id: I5514d4786b0895a3dbc5f515a4fd916dd36dc822
Reviewed-by: Orgad Shaneh

Update JGit to 3.5.3.201412180710-r

2015-09-23T17:56:30+00:00

This JGit version fixes:
- Bug 420915 - jgit gc hangs in partitionTasks with a very small repo
- Bug 427107 - cannot push anymore
The latter was observed by CollabNet to break Gerrit replication if gc
created a bitmap index which may have induced PackWriterBitmapWalker.
findObjects() to throw a MissingObjectException.

This version of JGit also fixes the recursive merger on all storage
systems.  Objects created during the virtual base construction of a
recursive merge must be written out somewhere and made available
through an ObjectReader for later passes to work on.

In both local filesystem and DFS implementations Gerrit was no-op'ing
the inserter in dry-run mode, causing these objects to be lost and
unavailable during the later processing stages of the merger.  With a
virtual common ancestor tree or blob missing, the dry-run merger fails
and a spurious merge conflict is reported.

Instead build a non-flushing inserter wrapper around a real inserter
for the repository. On local disk (standard storage) this will allow
the virtual base to write loose objects, which may be reclaimed in
about two weeks by the standard `git prune` invoked by `git gc`.

On DFS systems this will create a new pack file and buffer a block of
data in memory before starting to store to persistent storage.
However with no flush() the DfsInserter will attempt to rollback the
pack, which may allow the DFS system to reclaim its storage quickly.
Some implementations of DFS may buffer even more deeply than one
block, making the discard even cheaper for smaller merges.

This update also fixes a potential infinite loop during object
inflation within both the WindowCursor or DfsReader versions of
ObjectReader.  Inflation could get stuck if an object's compression
stream within a pack ended at a very precise alignment with the cache
block size.  The alignment problem is very rare, as it has taken
several years to identify and track down.

Includes changes done in I9859bd073bd710424e12b8b091abb8278f4f9fcc
on master.

Change-Id: I898ad7d5e836ebae0f8f84b17d0ae74489479ef9
(cherry picked from commit 2793c58dae47d1f96d642ec56e197ba2eb5af5b4)
Reviewed-by: Ismo Haataja 
Reviewed-by: Oswald Buddenhagen

Don't create empty cherry-picks

2015-09-23T17:56:04+00:00

If the tree after a cherry-pick is identical to the new parent's tree
the newly picked commit is empty.  This can happen if the commit is
being cherry-picked on top of another version of itself, or was
already included in the target branch.

Change-Id: I7e3fe9c02ca0b5182635a6e202b1d38e4dc39405
(cherry picked from commit fd889d9db648e6f027ee5d2e295041cb1bc3591a)
Reviewed-by: Oswald Buddenhagen

disarm automatic submodule update

2015-05-28T09:57:47+00:00

it's a bit insane that there is no config option for that. we have no
use for the feature as of now, so just break it globally.

Change-Id: I441bb66fc64c8a9fd4e4347f31166d3b5f3ccb13
Reviewed-by: Eike Ziller 
Reviewed-by: Ismo Haataja 
Reviewed-by: Oswald Buddenhagen

Allow gitweb URLs to be passed unencoded for viewing.

2015-03-03T16:47:11+00:00

Gerrit composes the viewer URL using information
about the project, branch, file or commit of the
target object to be displayed.

Context:
Typically viewers such as CGit and GitWeb do need
those parts to be encoded, including the '/' in
project names, for being correctly parsed.
However other viewers could instead require
unencoded URL (e.g. GitHub web based viewer).

This patch allows to disable the URL encoding for
allowing GitHub to be used as "gitweb custom viewer"
on top of Gerrit.

Example of GitHub configured as viewer:

[gitweb]
    type = custom
    url = https://github.com/
    project = ${project}
    revision = ${project}/commit/${commit}
    branch = ${project}/tree/${branch}
    fileHistory = ${project}/blog/${branch}/${file}
    linkName = GitHub
    urlEncode = false

Change-Id: Ief59de7eb19def60c5e765c4a495bcac00384d83
(cherry picked from commit 253120389509e82d3f71da53d596b3fbcd41cd3e)
Reviewed-by: Ismo Haataja 
Reviewed-by: Oswald Buddenhagen

Revert "Partially revert "Staging branch feature""

2015-03-03T16:46:24+00:00

This reverts commit 14d3b3c854276b148c2fcb53ce00d0f668de2306.

Conflicts:
	gerrit-server/src/main/java/com/google/gerrit/server/git/MergeOp.java

Change-Id: Ib3fa0e6b80bb6f30fe16af10e1805604cac1ab02
Reviewed-by: Ismo Haataja 
Reviewed-by: Oswald Buddenhagen

Fix updating changes that fail to merge

2015-03-03T16:46:18+00:00

If a submitted change fails to merge due an error (e.g. inconsistent
data or a pre merge validation found an issue) the change state should
be set back to 'New', but it stays as 'Submitted, Merge Pending'. It
should also display a proper error message to the user doing the
submit and add a change message to the change that contains the error
message. Both is currently not happening and the user has no idea why
the change got stuck in 'Submitted, Merge Pending' state.

This change ensures that all changes which cannot be merged due to an
error are properly updated.

Conflicts:
	gerrit-server/src/main/java/com/google/gerrit/server/git/MergeOp.java

Change-Id: Idd8da6a4cd089d2a7b09cbb60342612f1c5256e9
Signed-off-by: Edwin Kempin 
(cherry picked from commit 851f7017fd8728616406c605bd5b906706894bc7)
Reviewed-by: Ismo Haataja 
Reviewed-by: Oswald Buddenhagen

Limit retrying of submitted changes to 12 hours

2015-03-03T16:46:13+00:00

Recently we discovered a change that has been retrying submit every
5 minutes since November, 2012. The change is unsubmittable due to
an unresolved dependency.

isSubmitStillPossible() is potentially broken in this case and may
be allowing changes to wait forever rather than DEPENDENCY_DELAY (15
minutes). Although the project should also fix whatever underlying
cause exists here, changes should never be allowed to automatically
retry submit for more than 6 months with no human intervention.

Be more conservative by retrying a change for 12 hours. If an
identical failure message is going to be posted, abort the submit
by setting the change status back to NEW. This requires a human to
revisit the change.

Adjust where the secondary index is invoked to ensure it gets
updated after the change was modified by MergeOp.

Conflicts:
	gerrit-server/src/main/java/com/google/gerrit/server/git/MergeOp.java

Change-Id: I4b2b73c2edbf61459c398e4fcc5cad7d504ba8b0
(cherry picked from commit 06f92f721c7b40037172f661592bab89f6df9671)
Reviewed-by: Ismo Haataja 
Reviewed-by: Oswald Buddenhagen

Abandon any open changes if a project has been removed

2015-03-03T16:46:00+00:00

If the Git repository has been deleted and a change has been
submitted in that repository MergeOp will contiuously try to
submit changes in that project, failing on every attempt when
openRepository() fails.

Catch this failure and abandon all changes in the project, as the
Git data no longer exists.

Change-Id: I83087211b281c1e478c0e83b48b8f7d158a93c13
(cherry picked from commit 1eda8192c2ab1027ca499ddad6b7dfe79f29c189)
Reviewed-by: Ismo Haataja 
Reviewed-by: Oswald Buddenhagen