In findGraphPosition, when there is no object whose OID starts with
the first byte of the sought OID, low equals high. This violates an
invariant of the loop, and when the sought OID is lexicographically
greater than every other OID in the repository, causes an
ArrayIndexOutOfBoundsException (because we're trying to read outside the
list of OIDs).
Therefore, check the "low < high" condition at the start of the loop,
not only after the first iteration.
Change-Id: Ic8ac198c151bd161c4996b9e7cb6e6660f151733
Helped-by: Ivan Frade <ifrade@google.com>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
We need to update to Tycho in order to force PGP signing of the
bouncycastle libraries which isn't supported by earlier Tycho versions.
For that we need to run Maven on Java 17 or higher.
In order to run tests on Java 11 add a `toolchain.xml` file into the
`~/.m2` directory providing the path to Java installations:
<?xml version='1.0' encoding='UTF-8'?>
<toolchains>
<toolchain>
<type>jdk</type>
<provides>
<id>JavaSE-11</id>
<version>11</version>
</provides>
<configuration>
<jdkHome>/path/to/java-11</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<id>JavaSE-17</id>
<version>17</version>
</provides>
<configuration>
<jdkHome>/path/to/java-17</jdkHome>
</configuration>
</toolchain>
</toolchains>
Change-Id: Ib0f18147826e5b4a7fa1f41590772516269de702
This reverts commit 7e094c6cf3.
Reason: the maven artifact has a broken MANIFEST.MF with a mandatory
dependency to sun.security.x509, which is an internal package in the
JDK and moreover not needed by the bundle except for one test class
that isn't in the bundle at all.
This extra dependency makes the JGit tycho packaging build fail when
Tycho 4 is used.
We must keep using the Orbit re-packaging of this artifact, which does
not have this unnecessary mandatory dependency.
Change-Id: Ica15a5ddcada09686de3055b2b3daf081e3c5ffc
Signed-off-by: Thomas Wolf <twolf@apache.org>
If a method called in a finally block throws an exception we should add
exceptions caught earlier to the exception we throw in the finally block
not regarding if it's a checked or unchecked exception.
Change-Id: I4c6be9a3a08482b07659ca31d6987ce719d81ca5
Errorprone raises the following warning:
"[ReferenceEquality] Comparison using reference equality
instead of value equality".
Change-Id: Iacb207ef0625bb987a08406d4e7461e48fade97f
Bump the version numbers in pom.xml and in MANIFESTs, and in the bazel
WORKSPACE file. Update the target platforms. Remove work-arounds in
org.eclipse.jgit.ssh.apache that are no longer necessary.
The release notes for Apache MINA sshd are at [1].
[1] https://github.com/apache/mina-sshd/blob/master/docs/changes/2.10.0.md
Bug: 581770
Change-Id: Id27e73e9712b7865353c9b32b5b768f6e998b05e
Signed-off-by: Thomas Wolf <twolf@apache.org>
New static final constant is a (very minor) API break that needs to be
suppressed explicitly despite @since 6.6.
Remove a number of no longer needed API filters, and fix a broken
$NON-NLS-1$.
Change-Id: Ie4b0c45e8bd1f3067b6ff81c07d4b21b50bb8685
Signed-off-by: Thomas Wolf <twolf@apache.org>
During garbage collection, extensions for temporary files for indices
are formatted manually.
Add a method to PackExt to generate the temporary file extensions for
each type of index file programmatically.
Change-Id: I210bc2702e750bf0aea643b1a9a8536adebef179
Signed-off-by: Anna Papitto <annapapitto@google.com>
ServiceV2 is not collecting wants/have in PackStatistics. This records
the stats for fetch and push-negotiation.
Change-Id: Iefd79f36b3d7837195e8bd9fc7007de352089e66
PackWriter offers the ability to write out the pack file and its various
index files, except for the newly introduced file-based reverse index.
Now that PackReverseIndexWriter can write reverse index files,
PackWriter#writeReverseIndex will write one for a pack if the
corresponding config flag PackConfig#writeReverseIndex is on.
Change-Id: Ib75dd2bbfb9ee9366d5aacb46700d8cf8af4823a
Signed-off-by: Anna Papitto <annapapitto@google.com>
- com.github.siom79.japicmp:japicmp-maven-plugin to 0.17.2
- com.github.spotbugs:spotbugs-maven-plugin to 4.7.3.4
- maven-clean-plugin to 3.2.0
- maven-compiler-plugin to 3.11.0
- maven-deploy-plugin to 3.1.1
- maven-enforcer-plugin to 3.3.0
- maven-javadoc-plugin to 3.5.0
- maven-project-info-reports-plugin to 3.4.3
- maven-resources-plugin to 3.3.1
- maven-surefire-plugin to 3.0.0
- maven-surefire-report-plugin to 3.0.0
- org.codehaus.mojo:build-helper-maven-plugin to 3.3.0
- org.jacoco:jacoco-maven-plugin to 0.8.10
- org.springframework.boot:spring-boot-maven-plugin to 2.7.11
Change-Id: I42f3a09362a3b1afef65981cd3a862780f592af2
The in process lock is intended to manage contention on locking the
packed-refs file within a single process without acquiring the file
system lock. Not sharing it across RefDirectory instances of the same
repository undermines that intent and results in more contention at the
file system level.
Change-Id: I68f11856aa0b4b1524f43554d7391a322a0a6897
Signed-off-by: Nasser Grainawi <quic_nasserg@quicinc.com>
and consume it directly from Maven Central.
Its BundleSymbolicName changes to "org.apache.commons.commons-codec"
which is defined upstream.
Change-Id: Id9c366b3be0b97f4b191ba78f02001306f0e5035
and consume it directly from Maven Central.
Its BundleSymbolicName changes to "org.apache.commons.commons-compress"
which is defined upstream.
Change-Id: I691f5f49491dd2c9ba577ebe0c6f7cdd462c047a
This changes its BundleSymbolicName from "javaewah" (name in Orbit) to
com.googlecode.javaewah.JavaEWAH (name in upstream artefact from Maven
Central).
Change-Id: I8dee6909d496e3d05b2de938515dde831518be24
With completely independent branches, there is no merge base. In this
case, the list of commits must include the root commit of the branch to
be rebased.
Bug: 581832
Change-Id: I0f5bdf179d5b07ff09f1a274d61c7a0b1c0011c6
Signed-off-by: Thomas Wolf <twolf@apache.org>
Handle the case of the commit to be picked not having any parents.
Since JGit implements cherry-pick as a 3-way-merge between the commit
to be picked and the target commit, using the parent of the picked
commit as merge base, this is super simple: just don't set a base tree.
The merger will not find any merge base and will supply an empty tree
iterator for the base.
Bug: 581832
Change-Id: I88985f1b1723db5b35ce58bf228bc48d23d6fca3
Signed-off-by: Thomas Wolf <twolf@apache.org>
JGit's AddCommand always renormalizes tracked files. C git does so only
on git add --renormalize. Especially for git add . and the JGit
equivalent git.add().addFilepattern(".").call() this can make a big
difference if there are many files, or large files.
Add a "renormalize" option to AddCommand. To maintain compatibility with
existing uses, this option is "true" by default, and the behavior of
AddCommand is as it has always been in JGit.
If set to "false", use an IndexDiffFilter (in addition to a path filter,
if any). This skips any unchanged files (that are not racily clean) from
content checks. Note that changes in CRLF settings or in filters will be
ignored for such files if renormalize == false.
Add the "--renormalize" option to the Add command in the JGit command
line program. For the command-line program, the default is as in C git:
renormalize is off by default and enabled only if the option is given.
Note that --renormalize implies --update in the command line program, as
in C git. In AddCommand, the two settings are independent.
Additionally, avoid opening input streams unnecessarily in
WorkingTreeIterator.getEntryContentLength() and fix some bogus
indentation.
Add a simple test that adds 1000 files of 10kB in 10 directories twice
and that fails if the second invocation (without any changes) with
renormalize=false is not significantly faster.
Locally, I observe for that second invocation
* git.add().addFilepattern(".").call() ~660ms
* git.add().addFilepattern(".").setRenormalize(false).call() ~16ms
Bug: 494323
Change-Id: I30f9d518563fa55d7058a48c27c425f3b60aeb4c
Signed-off-by: Thomas Wolf <twolf@apache.org>