Merge branch 'stable-6.2' into stable-6.3

* stable-6.2:
  If tryLock fails to get the lock another gc has it
  Fix GcConcurrentTest#testInterruptGc
  Don't swallow IOException in GC.PidLock#lock
  Check if FileLock is valid before using or releasing it

Change-Id: I5b6b10622b61fde3f0f10455a74ae159a0b69082

Merge branch 'stable-6.1' into stable-6.2

* stable-6.1:
  If tryLock fails to get the lock another gc has it
  Fix GcConcurrentTest#testInterruptGc
  Don't swallow IOException in GC.PidLock#lock
  Check if FileLock is valid before using or releasing it

Change-Id: I3ffe92566cc145053bb762f612dd96bc6d542c62

Merge branch 'stable-6.0' into stable-6.1

* stable-6.0:
  If tryLock fails to get the lock another gc has it
  Fix GcConcurrentTest#testInterruptGc
  Don't swallow IOException in GC.PidLock#lock
  Check if FileLock is valid before using or releasing it

Change-Id: Idea23e555c024557d7e39a86efe25f609400b962

Merge branch 'stable-5.13' into stable-6.0

* stable-5.13:
  If tryLock fails to get the lock another gc has it
  Fix GcConcurrentTest#testInterruptGc
  Don't swallow IOException in GC.PidLock#lock
  Check if FileLock is valid before using or releasing it

Change-Id: I708d0936fa86b028e4da4e7e21f332f8b48ad293

If tryLock fails to get the lock another gc has it

Change-Id: Ifd3bbcc5e0591883b774d23256949a83010ea134

Fix GcConcurrentTest#testInterruptGc

With the new GC.PidLock interrupting a running GC throws a
ClosedByInterruptException.

Change-Id: I7ccea1ae9a43d4edfdab2fcfd1324c64cc22b38f

Don't swallow IOException in GC.PidLock#lock

This broke the test GcConcurrentTest#testInterruptGc which expects
ClosedByInterruptException when the thread doing gc is interrupted.

Change-Id: I89e02fc37aceeccb04c20cfc5b71cb8fa21793d6

Check if FileLock is valid before using or releasing it

Change-Id: I23ba67b61b9b03772f33a929c080c0d02b8c8652

Merge branch 'stable-6.2' into stable-6.3

* stable-6.2:
  Use Java 11 ProcessHandle to get pid of the current process
  Acquire file lock "gc.pid" before running gc
  Silence API errors introduced by 9424052f

Change-Id: I53cf9675deac0b588048d8224216d2a7e8bd16ec

Merge branch 'stable-6.1' into stable-6.2

* stable-6.1:
  Use Java 11 ProcessHandle to get pid of the current process
  Acquire file lock "gc.pid" before running gc
  Silence API errors introduced by 9424052f

Change-Id: I0562a4a224779ccf1e4cc1ff8f5a352e55ab220a

Merge branch 'stable-6.0' into stable-6.1

* stable-6.0:
  Use Java 11 ProcessHandle to get pid of the current process
  Acquire file lock "gc.pid" before running gc
  Silence API errors introduced by 9424052f

Change-Id: Ib9a2419253ffcbc90874adbfdb8129fee3178210

Use Java 11 ProcessHandle to get pid of the current process

Change-Id: I790f218601c1d5e1b39c4101e3b2708e76b9d782

Merge branch 'stable-5.13' into stable-6.0

* stable-5.13:
  Acquire file lock "gc.pid" before running gc
  Silence API errors introduced by 9424052f

Change-Id: Ibb5c46cb79377d2d2cd7d4586f31c86665d2851c

Acquire file lock "gc.pid" before running gc

Git guards gc by locking a lock file "gc.pid" before starting execution.
The lock file contains the pid and hostname of the process holding the
lock. Git tries to kill the process holding that lock if the lock file
wasn't modified in the last 12 hours and was started from the same host.

Teach JGit to acquire this lock before running gc but skip execution if
another process already holds the lock. Killing the other process could
be undesired if it's a long running application.

If the lock file wasn't modified in the last 12 hours try to lock it and
run gc if locking succeeds.

Register a shutdown hook for the lock file to ensure it is cleaned up if
the process is gracefully killed.

Change-Id: I00b838dcbf4fb0d03863bf7a2cd86b743c6c6971

Silence API errors introduced by 9424052f

Change-Id: Ia9e619a8fa06648086b583c994e4b107ae06c44d

Merge branch 'stable-6.2' into stable-6.3

* stable-6.2:
  Fix getPackedRefs to not throw NoSuchFileException
  Add pack options to preserve and prune old pack files
  Allow to perform PackedBatchRefUpdate without locking loose refs
  Document option "core.sha1Implementation" introduced in 59029aec

Change-Id: I765c7302ce84a6a9c28fdef29da2bfaa49477c6e

Merge branch 'stable-6.1' into stable-6.2

* stable-6.1:
  Fix getPackedRefs to not throw NoSuchFileException
  Add pack options to preserve and prune old pack files
  Allow to perform PackedBatchRefUpdate without locking loose refs
  Document option "core.sha1Implementation" introduced in 59029aec

Change-Id: Id32683d5f506e082d39af269803bccee0280cc27

Merge branch 'stable-6.0' into stable-6.1

* stable-6.0:
  Add pack options to preserve and prune old pack files
  Allow to perform PackedBatchRefUpdate without locking loose refs
  Document option "core.sha1Implementation" introduced in 59029aec

Change-Id: I876a38c2de8b7d5eaacd00e36b85599f88173221

Merge branch 'stable-5.13' into stable-6.0

* stable-5.13:
  Add pack options to preserve and prune old pack files
  Allow to perform PackedBatchRefUpdate without locking loose refs
  Document option "core.sha1Implementation" introduced in 59029aec

Change-Id: I423f410578f5bbe178832b80fef8998a5372182c

Fix getPackedRefs to not throw NoSuchFileException

Since Files.newInputStream is from java.nio package, it throws
java.nio.file.NoSuchFileException. This was missed in the change
I00da88e. Without this change, getPackedRefs fails with
NoSuchFileException when there is no packed-refs file in a project.

Change-Id: I93c202ddb73a0a5979af8e4d09e45f5645664b45
Signed-off-by: Prudhvi Akhil Alahari <quic_prudhvi@quicinc.com>

Add pack options to preserve and prune old pack files

Add the options
- pack.preserveOldPacks
- pack.prunePreserved

This allows to configure in git config if old packs should be preserved
during gc and pruned during the next gc.

The original implementation in 91132bb0 only allows to set these options
using the API.

Change-Id: I5b23ab4f317d12f5ccd234401419913e8263cc9a

Allow to perform PackedBatchRefUpdate without locking loose refs

Add another newBatchUpdate method in the RefDirectory where we can
control if the created PackedBatchRefUpdate will lock the loose refs or
not.

This can be useful in cases when we run programs which have exclusive
access to a Git repository and we know that locking loose refs is
unnecessary and just a performance loss.

Change-Id: I7d0932eb1598a3871a2281b1a049021380234df9
(cherry picked from commit cb90ed08526bd51f04e5d72e3ba3cf5bd30c11e4)

Document option "core.sha1Implementation" introduced in 59029aec

Bug: 580310
Change-Id: I10f3d6f6b5af7ab96683994c9cbd85e6c18a5084

Merge branch 'stable-6.2' into stable-6.3

* stable-6.2:
  Shortcut during git fetch for avoiding looping through all local refs
  FetchCommand: fix fetchSubmodules to work on a Ref to a blob
  Silence API warnings introduced by I466dcde6
  Allow the exclusions of refs prefixes from bitmap
  PackWriterBitmapPreparer: do not include annotated tags in bitmap
  BatchingProgressMonitor: avoid int overflow when computing percentage
  Speedup GC listing objects referenced from reflogs
  FileSnapshotTest: Add more MISSING_FILE coverage

Change-Id: I2ff386d9a096277360e6c7bd5535b49984620fb3

Merge branch 'stable-6.1' into stable-6.2

* stable-6.1:
  Shortcut during git fetch for avoiding looping through all local refs
  FetchCommand: fix fetchSubmodules to work on a Ref to a blob
  Silence API warnings introduced by I466dcde6
  Allow the exclusions of refs prefixes from bitmap
  PackWriterBitmapPreparer: do not include annotated tags in bitmap
  BatchingProgressMonitor: avoid int overflow when computing percentage
  Speedup GC listing objects referenced from reflogs
  FileSnapshotTest: Add more MISSING_FILE coverage

Change-Id: Iff2fba026b49463016015b2fae1a42cf76ee2dbb

Merge branch 'stable-6.0' into stable-6.1

* stable-6.0:
  Shortcut during git fetch for avoiding looping through all local refs
  FetchCommand: fix fetchSubmodules to work on a Ref to a blob
  Silence API warnings introduced by I466dcde6
  Allow the exclusions of refs prefixes from bitmap
  PackWriterBitmapPreparer: do not include annotated tags in bitmap
  BatchingProgressMonitor: avoid int overflow when computing percentage
  Speedup GC listing objects referenced from reflogs
  FileSnapshotTest: Add more MISSING_FILE coverage

Change-Id: Ib5055f2f3b8a313c178d6f6c7c5630285ad5a726

Merge branch 'stable-5.13' into stable-6.0

* stable-5.13:
  Shortcut during git fetch for avoiding looping through all local refs
  FetchCommand: fix fetchSubmodules to work on a Ref to a blob
  Silence API warnings introduced by I466dcde6
  Allow the exclusions of refs prefixes from bitmap
  PackWriterBitmapPreparer: do not include annotated tags in bitmap
  BatchingProgressMonitor: avoid int overflow when computing percentage
  Speedup GC listing objects referenced from reflogs
  FileSnapshotTest: Add more MISSING_FILE coverage

Change-Id: I58ad4c210a5e7e5a1ba6b22315b04211c8909950

Shortcut during git fetch for avoiding looping through all local refs

The FetchProcess needs to verify that all the refs received point
to objects that are reachable from the local refs, which could be
very expensive but is needed to avoid missing objects exceptions
because of broken chains.

When the local repository has a lot of refs (e.g. millions) and the
client is fetching a non-commit object (e.g. refs/sequences/changes in
Gerrit) the reachability check on all local refs can be very expensive
compared to the time to fetch the remote ref.

Example for a 2M refs repository:
- fetching a single non-commit object: 50ms
- checking the reachability of local refs: 30s

A ref pointing to a non-commit object doesn't have any parent or
successor objects, hence would never need to have a reachability check
done. Skipping the askForIsComplete() altogether would save the 30s
time spent in an unnecessary phase.

Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com>
Change-Id: I09ac66ded45cede199ba30f9e71cc1055f00941b

FetchCommand: fix fetchSubmodules to work on a Ref to a blob

FetchCommand#fetchSubmodules assumed that FETCH_HEAD can always be
parsed as a tree. This isn't true if it refers to a Ref referring to a
BLOB. This is e.g. used in Gerrit for Refs like refs/sequences/changes
which are used to implement sequences stored in git.

Change-Id: I414f5b7d9f2184b2d7d53af1dfcd68cccb725ca4

Silence API warnings introduced by I466dcde6

Change-Id: I510510da34d33757c2f83af8cd1e26f6206a486a

Allow the exclusions of refs prefixes from bitmap

When running a GC.repack() against a repository with over one
thousands of refs/heads and tens of millions of ObjectIds,
the calculation of all bitmaps associated with all the refs
would result in an unreasonable big file that would take up to
several hours to compute.

Test scenario: repo with 2500 heads / 10M obj Intel Xeon E5-2680 2.5GHz
Before this change: 20 mins
After this change and 2300 heads excluded: 10 mins (90s for bitmap)

Having such a large bitmap file is also slow in the runtime
processing and have negligible or even negative benefits, because
the time lost in reading and decompressing the bitmap in memory
would not be compensated by the time saved by using it.

It is key to preserve the bitmaps for those refs that are mostly
used in clone/fetch and give the ability to exlude some refs
prefixes that are known to be less frequently accessed, even
though they may actually be actively written.

Example: Gerrit sandbox branches may even be actively
used and selected automatically because its commits are very
recent, however, they may bloat the bitmap, making it ineffective.

A mono-repo with tens of thousands of developers may have
a relatively small number of active branches where the
CI/CD jobs are continuously fetching/cloning the code. However,
because Gerrit allows the use of sandbox branches, the
total number of refs/heads may be even tens to hundred
thousands.

Change-Id: I466dcde69fa008e7f7785735c977f6e150e3b644
Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com>

PackWriterBitmapPreparer: do not include annotated tags in bitmap

The annotated tags should be excluded from the bitmap associated
with the heads-only packfile. However, this was not happening
because of the check of exclusion of the peeled object instead
of the objectId to be excluded from the bitmap.

Sample use-case:

refs/heads/main
  ^
  |
 commit1 <-- commit2 <- annotated-tag1 <- tag1
  ^
  |
 commit0

When creating a bitmap for the above commit graph, before this
change all the commits are included (3 bitmaps), which is
incorrect, because all commits reachable from annotated tags
should not be included.

The heads-only bitmap should include only commit0 and commit1
but because PackWriterBitPreparer was checking for the peeled
pointer of tag1 to be excluded (commit2) which was not found in
the list of tags to exclude (annotated-tag1), the commit2 was
included, even if it wasn't reachable only from the head.

Add an additional check for exclusion of the original objectId
for allowing the exclusion of annotated tags and their pointed
commits. Add one specific test associated with an annotated tag
for making sure that this use-case is covered also.

Example repository benchmark for measuring the improvement:
# refs: 400k (2k heads, 88k tags, 310k changes)
# objects: 11M (88k of them are annotate tags)
# packfiles: 2.7G

Before this change:
GC time: 5h
clone --bare time: 7 mins

After this change:
GC time: 20 mins
clone --bare time: 3 mins

Bug: 581267
Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com>
Change-Id: Iff2bfc6587153001837220189a120ead9ac649dc

BatchingProgressMonitor: avoid int overflow when computing percentage

When cloning huge repositories I observed percentage of object counts
turning negative. This happened if lastWork * 100 exceeded
Integer.MAX_VALUE.

Change-Id: Ic5f5cf5a911a91338267aace4daba4b873ab3900

Speedup GC listing objects referenced from reflogs

GC needs to get a ReflogReader for all existing refs to list all objects
referenced from reflogs. The existing Repository#getReflogReader method
accepts the ref name and then resolves the Ref to create a ReflogReader.
GC calling that for a huge number of Refs one by one is very slow. GC
first gets all Refs in bulk and then calls getReflogReader for each of
them.

Fix this by adding another getReflogReader method to Repository which
accepts a Ref directly.

This speeds up running JGit gc on a mirror clone of the Gerrit
repository from 15:36 min to 1:08 min. The repository used in this test
had 45k refs, 275k commits and 1.2m git objects.

Change-Id: I474897fdc6652923e35d461c065a29f54d9949f4

Merge branch 'stable-6.2' into stable-6.3

* stable-6.2:
  Cache trustFolderStat/trustPackedRefsStat value per-instance
  Refresh 'objects' dir and retry if a loose object is not found

Change-Id: Ibc9bffab8c9ef9c39384b53c142d99878f7f3f98

Merge branch 'stable-6.1' into stable-6.2

* stable-6.1:
  Cache trustFolderStat/trustPackedRefsStat value per-instance
  Refresh 'objects' dir and retry if a loose object is not found

Change-Id: I9e876f72f735f58bf02c7862a3d8e657fc46a7b9

Cache trustFolderStat/trustPackedRefsStat value per-instance

Instead of re-reading the config every time the methods using these
values were called, cache the config value at the time of instance
construction. Caching the values improves performance for each of the
method calls. These configs are set based on the filesystem storing the
repository and unlikely to change while an application is running.

Change-Id: I1cae26dad672dd28b766ac532a871671475652df
Signed-off-by: Nasser Grainawi <quic_nasserg@quicinc.com>

Refresh 'objects' dir and retry if a loose object is not found

A new loose object may not be immediately visible on a NFS
client if it was created on another client. Refreshing the
'objects' dir and trying again can help work around the NFS
behavior.

Here's an E2E problem that this change can help fix. Consider
a Gerrit multi-primary setup with repositories based on NFS.
Add a new patch-set to an existing change and then immediately
fetch the new patch-set of that change. If the fetch is handled
by a Gerrit primary different that the one which created the
patch-set, then we sometimes run into a MissingObjectException
that causes the fetch to fail.

Bug: 581317
Change-Id: Iccc6676c68ef13a1e8b2ff52b3eeca790a89a13d
Signed-off-by: Kaushik Lingarkar <quic_kaushikl@quicinc.com>

FileSnapshotTest: Add more MISSING_FILE coverage

Add a couple tests that confirm what the docs say about isModified() and
equals(MISSING_FILE) behavior.

Change-Id: I6093040ba3594934c3270331405a44b2634b97c5
Signed-off-by: Nasser Grainawi <quic_nasserg@quicinc.com>

Merge branch 'stable-6.2' into stable-6.3

* stable-6.2:
  Introduce core.trustPackedRefsStat config
  Fix documentation for core.trustFolderStat

Change-Id: I48b6c095ac62dc859829d6fef45325accbb0a144

Merge branch 'stable-6.1' into stable-6.2

* stable-6.1:
  Introduce core.trustPackedRefsStat config
  Fix documentation for core.trustFolderStat

Change-Id: Ic78630f74c72624932a384eed52ef79ae1eff3e5

Introduce core.trustPackedRefsStat config

Currently, we always read packed-refs file when 'trustFolderStat'
is false. Introduce a new config 'trustPackedRefsStat' which takes
precedence over 'trustFolderStat' when reading packed refs. Possible
values for this new config are:

* always: Trust packed-refs file attributes
* after_open: Same as 'always', but refresh the file attributes of
              packed-refs before trusting it
* never: Always read the packed-refs file
* unset: Fallback to 'trustFolderStat' to determine if the file
  attributes of packed-refs can be trusted

Folks whose repositories are on NFS and have traditionally been
setting 'trustFolderStat=false' can now get some performance improvement
with 'trustPackedRefsStat=after_open' as it refreshes the file
attributes of packed-refs (at least on some NFS clients) before
considering it.

For example, consider a repository on NFS with ~500k packed-refs. Here
are some stats which illustrate the improvement with this new config
when reading packed refs on NFS:

trustFolderStat=true trustPackedRefsStat=unset: 0.2ms
trustFolderStat=false trustPackedRefsStat=unset: 155ms
trustFolderStat=false trustPackedRefsStat=after_open: 1.5ms

Change-Id: I00da88e4cceebbcf3475be0fc0011ff65767c111
Signed-off-by: Kaushik Lingarkar <quic_kaushikl@quicinc.com>

Fix documentation for core.trustFolderStat

Update documentation for core.trustFolderStat to highlight that it is
also used when reading the packed-refs file.

Change-Id: I3eac377c3a7f48493abc8ae6d0889ee70a05d24d
Signed-off-by: Kaushik Lingarkar <quic_kaushikl@quicinc.com>

Merge branch 'stable-6.2' into stable-6.3

* stable-6.2:
  Remove unused imports
  Suppress non-externalized String warnings
  Remove unused API problem filters
  Silence API errors
  Silence API errors
  Silence API warnings

Change-Id: I71aa9f890c5eb05849ad16a00b9974da5e51171e

Remove unused imports

Change-Id: I57a3ae0a8608a517d9cc5cc27cee136f9faeb810

Suppress non-externalized String warnings

Change-Id: I95c61bd906bd3f7cdea9581e0ffa92ec607c6140

Remove unused API problem filters

Change-Id: I890716bc052dcce2ce136040035b442247c08332

Merge branch 'stable-6.1' into stable-6.2

* stable-6.1:
  Silence API errors
  Silence API errors
  Silence API warnings

Change-Id: Id3efa1b32710661cde63e93c5b8832785a805415

Silence API errors

Change-Id: I07c42fe9417edb0570dd475a7e935112a878a93b

Merge branch 'stable-6.0' into stable-6.1

* stable-6.0:
  Silence API errors
  Silence API warnings

Change-Id: I2b8336652e60dec97666582cf9331c8505729473

Silence API errors

Change-Id: Ie112b2099ea2125bc85863524e56f09ba4907373

Merge branch 'stable-5.13' into stable-6.0

* stable-5.13:
  Silence API warnings

Change-Id: If5ab988a0e177c37b125e0b10625e506eeb2a74f

Silence API warnings

introduced by
- addition of configurable SHA1 implementation in 5.13.2
- 3-digit @since 5.9.1 annotations on GitServlet methods

Change-Id: If19853fcc5e3677e5b18e8e3fbbcd2773378dffc

Merge branch 'stable-6.2' into stable-6.3

* stable-6.2:
  Extract Exception -> HTTP status code mapping for reuse
  Don't handle internal git errors as an HTTP error
  Allow to perform PackedBatchRefUpdate without locking loose refs

Change-Id: I562be0802efa231023c5f10e6461339b2d7fbacf

Merge branch 'stable-6.1' into stable-6.2

* stable-6.1:
  Extract Exception -> HTTP status code mapping for reuse
  Don't handle internal git errors as an HTTP error
  Allow to perform PackedBatchRefUpdate without locking loose refs

Change-Id: Icb321779184d20f3871e236fda1a3acba605a6da

Merge "Merge branch 'stable-6.0' into stable-6.1" into stable-6.1

Merge branch 'stable-6.2' into stable-6.3

* stable-6.2:
  [benchmarks] Remove profiler configuration
  Add SHA1 benchmark
  [benchmarks] Set version of maven-compiler-plugin to 3.8.1
  Fix running JMH benchmarks
  Add option to allow using JDK's SHA1 implementation
  Ignore IllegalStateException if JVM is already shutting down

Change-Id: I9c1576011c11b4ff8f453d18d9e786cee59860fa

Merge branch 'stable-6.1' into stable-6.2

* stable-6.1:
  [benchmarks] Remove profiler configuration
  Add SHA1 benchmark
  [benchmarks] Set version of maven-compiler-plugin to 3.8.1
  Fix running JMH benchmarks
  Add option to allow using JDK's SHA1 implementation
  Ignore IllegalStateException if JVM is already shutting down

Change-Id: Ie433c46a01a0f33848d54ecf99b30a44ca01e286

Merge branch 'stable-6.0' into stable-6.1

* stable-6.0:
  [benchmarks] Remove profiler configuration
  Add SHA1 benchmark
  [benchmarks] Set version of maven-compiler-plugin to 3.8.1
  Fix running JMH benchmarks
  Add option to allow using JDK's SHA1 implementation
  Ignore IllegalStateException if JVM is already shutting down

Change-Id: I176419026c3f4fdd8ebd34c61468c1ec3482ff45

Merge branch 'stable-5.13' into stable-6.0

* stable-5.13:
  [benchmarks] Remove profiler configuration
  Add SHA1 benchmark
  [benchmarks] Set version of maven-compiler-plugin to 3.8.1
  Fix running JMH benchmarks
  Add option to allow using JDK's SHA1 implementation
  Ignore IllegalStateException if JVM is already shutting down

Change-Id: I40105336f0b9e593a8a2c242a9557f854c274fdc

[benchmarks] Remove profiler configuration

Profiler configuration can be added when required. It was commented out
in most benchmarks.

Change-Id: I725f98757f7d4d2ba2589658e34e2fd6fbbbedee

Add SHA1 benchmark

Results on a Mac M1 max:

    size     SHA1Native SHA1Java    SHA1Java
                        without     with
                        collision   collision
                        detection   detection
    [kB]     [us/op]    [us/op]     [us/op]
---------------------------------------------
      1       3.662       4.200       4.707
      2       7.053       7.868       8.928
      4      13.883      15.149      17.608
      8      27.225      30.049      35.237
     16      54.014      59.655      70.867
     32     106.457     118.022     140.403
     64     212.712     237.702     281.522
   1024    3469.519    3868.883    4637.287
 131072  445011.724  501751.992  604061.308
1048576 3581702.104 4008087.854 4831023.563

The last 3 sizes (1, 128, 1024 MB) weren't committed
here to limit the total runtime.

Bug: 580310
Change-Id: I7d0382fd4aa4c4734806b12e96b671bee37d26e3

[benchmarks] Set version of maven-compiler-plugin to 3.8.1

Change-Id: Ib14db133c76a55358ea79663ef38d9fb47a67f45

Fix running JMH benchmarks

Without this I sometimes hit the error:

$ java -jar target/benchmarks.jar
Exception in thread "main" java.lang.RuntimeException: ERROR: Unable to
find the resource: /META-INF/BenchmarkList
at org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:98)
at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:124)
at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:253)
at org.openjdk.jmh.runner.Runner.run(Runner.java:209)
at org.openjdk.jmh.Main.main(Main.java:71)

Change-Id: Iea9431d5f332f799d55a8a2d178c79a2ef0da22b

Add option to allow using JDK's SHA1 implementation

The change If6da9833 moved the computation of SHA1 from the JVM's
JCE to a pure Java implementation with collision detection.
The extra security for public sites comes with a cost of slower
SHA1 processing compared to the native implementation in the JDK.

When JGit is used internally and not exposed to any traffic from
external or untrusted users, the extra cost of the pure Java SHA1
implementation can be avoided, falling back to the previous
native MessageDigest implementation.

Bug: 580310
Change-Id: Ic24c0ba1cb0fb6282b8ca3025ffbffa84035565e

Fix API breakage caused by extracting WorkTreeUpdater

448052dc2e made WorkTreeUpdater package visible which breaks API for
subclasses of ResolveMerger since they cannot access WorkTreeUpdater.

Fix this by moving WorkTreeUpdater into ResolveMerger as a nested class
and mark it protected so that subclasses can use it.

Bug: 581049
Change-Id: I5a2c4953f8514dc0a1b8041c8e069d28370bb2eb

Extract Exception -> HTTP status code mapping for reuse

Extract private static method UploadPackServlet#statusCodeForThrowable
to a public static method in the UploadPackErrorHandler interface so
that implementers of this interface can reuse the default mapping.

Change-Id: Ie4a0a006b0148d5b828d610c55d19ce407aab055

Don't handle internal git errors as an HTTP error

The fix that fixed the propagation of error-codes:
  8984e1f66 HTTP Smart: set correct HTTP status on error [1]
made some faulty assumptions.

"Wants not valid", can be an intermittent git error and the HTTP
response should be 200 and not 400 since the request isn't necessary
faulty.

[1] https://git.eclipse.org/r/c/jgit/jgit/+/192677

Bug: 579676
Change-Id: I461bc78ff6e450636811ece50d21c57a2a7f2ae3

Ignore IllegalStateException if JVM is already shutting down

Trying to register/unregister a shutdown hook when the JVM is already in
shutdown throws an IllegalStateException. Ignore this exception since we
can't do anything about it.

Bug: 580953
Change-Id: I8fc6fdd5585837c81ad0ebd6944430856556d90e

Allow to perform PackedBatchRefUpdate without locking loose refs

Add another newBatchUpdate method in the RefDirectory where we can
control if the created PackedBatchRefUpdate will lock the loose refs or
not.

This can be useful in cases when we run programs which have exclusive
access to a Git repository and we know that locking loose refs is
unnecessary and just a performance loss.

Change-Id: I7d0932eb1598a3871a2281b1a049021380234df9

Remove unused imports

Change-Id: Ib6f80a5f013d30a9b7a59cb05e3ee13aa46b28c8

Prepare 6.3.1-SNAPSHOT builds

Change-Id: I44e159eca4131880d74d3078060e7e20f9b5ce76

JGit v6.3.0.202209071007-r

Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Change-Id: Iea3fae9f6f6c5fb0a79f7684334a3e0059738c4f

JGit v6.3.0.2022009070944-r

Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Change-Id: I3cc78dbcf8c7970e80bf1499751611110ec2b30b

[merge] Fix merge conflicts with symlinks

Previous code would do a content merge on symlinks, and write the merge
result to the working tree as a file. C git doesn't do this; it leaves
a symlink in the working tree unchanged, or in a delete-modify conflict
it would check out "theirs".

Moreover, previous code would write the merge result to the link target,
not to the link. This would overwrite an existing link target, or fail
if the link pointed to a directory.

In link/file conflicts or file/link conflicts, C git always puts the
file into the working tree.

Change conflict handling accordingly. Add tests for all the conflict
cases.

Bug: 580347
Change-Id: I3cffcb4bcf8e336a85186031fff23f0c4b6ee19d
Signed-off-by: Thomas Wolf <twolf@apache.org>

Update DEPENDENCIES for 6.3.0

Change-Id: Ie057e4c94a102113fc9026d9773657984530c9c6

Update tycho to 2.7.5

Change-Id: I5ef981cf9f01cc8493dc6178938819f5e086f26a

Merge branch 'master' into stable-6.3

* master:
  Move WorkTreeUpdater to merge package
  WorkTreeUpdater: use DirCacheCheckout#StreamSupplier
  DirCacheCheckout#getContent: also take InputStream supplier
  WorkTreeUpdater: remove safeWrite option

Change-Id: I8be570dbc4ad0d0b46046b85cbda24c3adcba170

Merge changes I888f313f,I98de155c,I2efa9a6d,Ifa79dac2

* changes:
  Move WorkTreeUpdater to merge package
  WorkTreeUpdater: use DirCacheCheckout#StreamSupplier
  DirCacheCheckout#getContent: also take InputStream supplier
  WorkTreeUpdater: remove safeWrite option

Move WorkTreeUpdater to merge package

This avoids making it public with the associated costs for backward
compatibility guarantees.

Change-Id: I888f313f3854deace8d4cd92f354a6ef0d3b5460

WorkTreeUpdater: use DirCacheCheckout#StreamSupplier

This avoids having to introduce the StreamLoader bridging class.

Change-Id: I98de155c458745236df24d6323eabed5061e7f8c

DirCacheCheckout#getContent: also take InputStream supplier

This lets us use DirCacheCheckout for routines that want to write
files in the worktree that aren't available as a git object.

DirCacheCheckout#getContent takes a InputStream supplier rather than
InputStream: if filtering fails with IOException, the data is placed
unfiltered in the checkout. This means that the stream has to be read
again, from the start.

Use it in this way in ApplyCommand. This use is incorrect, though: the
same InputStream is returned twice, so if the read to be retried, the
stream will return 0 bytes. It doesn't really matter, because in
either case, the SHA1 will not match up, and the patch fails.

Change-Id: I2efa9a6da06806ff79b155032fe4b34be8fec09e

Revert "Adds FilteredRevCommit that can overwrites its parents in the
DAG."

This reverts commit 6297491e8adb85e43d60ffe75fb71f335e733449.

This is done as a quick fix for the failure of egit tests caused by  the
introduction of FilteredRevCommit.

Bug: 580690
Change-Id: Ia6b651dd11b0a4b02d5e52247eb4bf13adf94e27

Revert "Option to pass start RevCommit to be blamed on to the
BlameGenerator."

This reverts commit 5747bba48b22a11beba8ebe0caf13a53d4ca96f2.

This is done as a quick fix for the failure of egit tests caused by  the
introduction of FilteredRevCommit.

Bug: 580690
Change-Id: Ia0178bc2de4fc825a81207bbd7979bf3a386c955

WorkTreeUpdater: remove safeWrite option

This was added in Ideaefd5178 to anticipate on writing files for
ApplyCommand, but we are keeping WorkTreeUpdater private to the merge
package for now.

Change-Id: Ifa79dac245e60eb7a77eaea4cc1249222e347d38

Merge branch 'master' into stable-6.3

* master:
  Update Orbit to R20220830213456 for 2022-09
  BaseSuperprojectWriter: report invalid paths as manifest errors
  ApplyCommand: fix ApplyResult#updatedFiles
  WorkTreeUpdater: rename metadata maps
  WorkTreeUpdater#Result: hide data members
  Add javadoc on RevCommit
  Option to pass start RevCommit to be blamed on to the BlameGenerator.
  WorkTreeUpdater: re-format and clean-up
  Adds FilteredRevCommit that can overwrites its parents in the DAG.

Change-Id: Ie92037b78b54c4ab290db80034e3192b1f90a1fc

Update Orbit to R20220830213456 for 2022-09

Change-Id: Iab04fd9e72102abe3d9d927a5cae4a1df2001aa2

BaseSuperprojectWriter: report invalid paths as manifest errors

An invalid path in the manifest (e.g. '.') is reported by DirCache in a
runtime exception. In server context this becomes a 500 instead of a user error.

Wrap the runtime invalid path exception into a checked ManifestErrorException that
caller can handle.

Change-Id: I61a2104922765506ae232334891057bb06141d97

ApplyCommand: fix ApplyResult#updatedFiles

On executing a copy, mark the destination as updated.

On executing a rename, mark both source and destination as updated.

Change-Id: Ied5b9b0e5a14eac59a06cdd0961e25e143f50ff0

WorkTreeUpdater: rename metadata maps

Change-Id: I8ff3803da8fc13377d11c2dc5523e9e32d0650cb

WorkTreeUpdater#Result: hide data members

This is the standard across JGit.

Change-Id: Ie52ad7000d8725657b33dd4f3adcc05ab9666875

Merge "WorkTreeUpdater: re-format and clean-up"

Add javadoc on RevCommit

Change-Id: Ib413154fe52983286cb6307862a7373af4fec6e8

Option to pass start RevCommit to be blamed on to the BlameGenerator.

This can allow passing a FilteredRevCommit which is the filtered list of
commit graph making it easier for Blame to work on. This can
significantly improve blame performance since blame can skip expensive
RevWalk.

Change-Id: Ie127cb710d004079e9f53a5802130afdb49a7de1

WorkTreeUpdater: re-format and clean-up

Reformat using the standard JGit formatter settings. Clean-ups:

* Try to improve javadoc.
* Remove blindly copy-pasted "@since 6.1" annotations.
* Get rid of private method nonNullNonBareRepo(); it's not needed.
* Simplify method nonNullRepo(), and annotate as @NonNull.
* Rename setInCoreFileSizeLimit() to getInCoreFileSizeLimit().

Change-Id: Ib1797e7cf925d87554307468330971e8ab2e05e9
Signed-off-by: Thomas Wolf <twolf@apache.org>
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>

Prepare 6.3.0-SNAPSHOT builds

Change-Id: Ie398b651c5308ec86812bf01fcc563d3e679c828

Adds FilteredRevCommit that can overwrites its parents in the DAG.

Change-Id: I1ea63a3b56074099688fc45d6a22943a8ae3c2ae

JGit v6.3.0.202208161710-m3

Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Change-Id: I0954d11a1f35eff196b157df3aa8386476c48a7e

Merge changes Ib6689f54,I3b5c22ee

* changes:
  Remove unused API problem filters
  Add missing @since tag for RevCommit#parents introduced in 61b4d105e4

DirCacheCheckout: load WorkingTreeOptions only once

Previous code loaded the WorkingTreeOptions afresh for every single
file being checked out. This checked the git config (all three files,
repo, user and system config) for having been modified every time.

These checks can be costly, for instance on Windows, or if one of the
three config files is not on a local disk, or on an otherwise slow
storage.

Improve this by loading the options and thus checking the git config
only once before the checkout.

Bug: 579715
Change-Id: I21cd5a808f9d90b5ca2d022f91f0eeb8ca26091c
Signed-off-by: Thomas Wolf <twolf@apache.org>