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.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.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.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

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>

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>

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 "Merge branch 'stable-6.0' into stable-6.1" into stable-6.1

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

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

Merge branch 'stable-6.0' into stable-6.1

* stable-6.0:
  UploadPack: don't prematurely terminate timer in case of error
  Do not create reflog for remote tracking branches during clone
  UploadPack: do not check reachability of visible SHA1s
  Add missing package import javax.management to org.eclipse.jgit

Change-Id: I08734ee2c8f3296d908da6a29d53ed87c4b48eb2

Merge branch 'stable-5.13' into stable-6.0

* stable-5.13:
  UploadPack: don't prematurely terminate timer in case of error
  Do not create reflog for remote tracking branches during clone
  UploadPack: do not check reachability of visible SHA1s
  Add missing package import javax.management to org.eclipse.jgit

Change-Id: I6db0a4d74399fde892eeec62efd2946f97547a5d

UploadPack: don't prematurely terminate timer in case of error

In uploadWithExceptionPropagation don't prematurely terminate timer in
case of error to enable reporting it to the client. Expose a close
method so that callers can terminate it at the appropriate time.

If the timer is already terminated when trying to report it to the
client this failed with the error java.lang.IllegalStateException:
"Timer already terminated".

Bug: 579670
Change-Id: I95827442ccb0f9b1ede83630cf7c51cf619c399a

Merge "Do not create reflog for remote tracking branches during clone" into stable-5.13

Do not create reflog for remote tracking branches during clone

When using JGit on a non-bare repository, the CloneCommand
it previously created local reflogs for all branches including remote
tracking ones, causing the generation of a potentially large
number of files on the local filesystem.

The creation of the remote-tracking branches (refs/remotes/*) during
clone is not an issue for the local filesystem because all of them are
stored in a single packed-refs file. However, the creation of a large
number of ref logs on a local filesystem IS an issue because it
may not be tuned or initialised in term of inodes to contain a very
large number of files.

When a user (or a CI system) performs the CloneCommand against
a potentially large repository (e.g., millions of branches), it is
interested in working or validating a single branch or tag and is
unlikely to work with all the remote-tracking branches.
The eager creation of a reflogs for all the remote-tracking branches is
not just a performance issue but may also compromise the ability to
use JGit for cloning a large repository.

The behaviour implemented in this change is also consistent with the
optimisation done in the C code-base [1].

We differentiate between clone and fetch commands using --branch
<initialBranch> option, that is only available in clone command,
and is set as HEAD per default.

[1] https://github.com/git/git/commit/58f233ce1ed67bbc31a429fde5c65d5050fdbd7d

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

UploadPack: do not check reachability of visible SHA1s

When JGit needs to serve a Git client requesting SHA1s
during the want phase, it needs to make a full reachability
check from the advertised refs to the ones requested to
keep all objects in the correct scope of confidentiality
allowed by the avertised refs.

The check is also performed when the SHA1 corresponds to
one of the tips of the advertised refs which is a waste of
resources.

Example:

fetch> ref-prefix refs/heads/foo
fetch< 900505eb8ce8ced2a1757906da1b25c357b9654e refs/heads/foo
fetch< 0000
fetch> command=fetch
fetch> 0001
fetch> thin-pack
fetch> ofs-delta
fetch> want 900505eb8ce8ced2a1757906da1b25c357b9654e

The SHA1 in the want is the tip of refs/heads/foo and therefore
the full reachability check can be shortened and resolved more
quickly.

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

Add missing package import javax.management to org.eclipse.jgit

Class org.eclipse.jgit.util.Monitoring uses JMX hence we need this
import otherwise OSGi applications can face ClassNotFoundException.

Bug: 577018
Change-Id: Ifd75337b87c7faec95d333b771bb0a2f3e46a418

Merge branch 'stable-6.0' into stable-6.1

* stable-6.0:
  Prepare 5.13.2-SNAPSHOT builds
  JGit v5.13.1.202206130422-r
  AmazonS3: Add support for AWS API signature version 4

Change-Id: Ie9c38ab8033fe1283e8b444b6acd3f4298062bf3

Merge branch 'stable-5.13' into stable-6.0

* stable-5.13:
  Prepare 5.13.2-SNAPSHOT builds
  JGit v5.13.1.202206130422-r
  AmazonS3: Add support for AWS API signature version 4

Change-Id: Ibd663a1d874d1aac274abc3dd44354fd99f64c39

Prepare 5.13.2-SNAPSHOT builds

Change-Id: I4862e5d80a7d95a1a119d06306e3f6927445d1d3

JGit v5.13.1.202206130422-r

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

AmazonS3: Add support for AWS API signature version 4

Updating the AmazonS3 class to support AWS Signature version 4 because
version 2 is no longer supported in all AWS regions. The version can be
selected with the new 'aws.api.signature.version' property (defaults to
2 for backwards compatibility). When set to '4', the user must also
specify the AWS region via the 'region' property. The 'region' property
must match the region that the 'domain' property resolves to.

Bug: 579907
Change-Id: If289dbc6d0f57323cfeaac2624c4eb5028f78d13

Merge branch 'stable-6.0' into stable-6.1

* stable-6.0:
  Fix connection leak for smart http connections

Change-Id: I8b7e643b87c0f788cdafb060a2c9e8b4ef6f7375

Merge branch 'stable-5.13' into stable-6.0

* stable-5.13:
  Fix connection leak for smart http connections

Change-Id: Ic851f2c4660ed761f5527e405b116b54da42fb7c

Merge branch 'stable-5.12' into stable-5.13

* stable-5.12:
  Fix connection leak for smart http connections

Change-Id: Id34f29c1b27a80c2b56c911cad7e3f64ef63af48

Merge branch 'stable-5.11' into stable-5.12

* stable-5.11:
  Fix connection leak for smart http connections

Change-Id: I6caabf4774ccf34706cef846c1087710f67e2ecd

Merge branch 'stable-5.10' into stable-5.11

* stable-5.10:
  Fix connection leak for smart http connections

Change-Id: I3885c6114caed897f762f5ce523d3b27288205b2

Merge branch 'stable-5.9' into stable-5.10

* stable-5.9:
  Fix connection leak for smart http connections

Change-Id: I5e7144b2f5cd850978220c476947001ae2debb8e

Fix connection leak for smart http connections

SmartHttpPushConnection: close InputStream and OutputStream after
processing. Wrap IOExceptions which aren't TransportExceptions already
as a TransportException.

Also-By: Matthias Sohn <matthias.sohn@sap.com>
Change-Id: I8e11d899672fc470c390a455dc86367e92ef9076

Merge branch 'stable-6.0' into stable-6.1

* stable-6.0:
  Remove stray files (probes or lock files) created by background threads

Change-Id: Iab21b9776c2ebecd4cad5d015028cadd4b6541db

Merge branch 'stable-5.13' into stable-6.0

* stable-5.13:
  Remove stray files (probes or lock files) created by background threads

Change-Id: I7af1355a77f14995118145162f6bb8a4f1755f2b

Remove stray files (probes or lock files) created by background threads

NOTE: port back from master branch.

On process exit, it was possible that the filesystem timestamp
resolution measurement left behind .probe files or even a lock file
for the jgit.config.

Ensure the SAVE_RUNNER is shut down when the process exits (via
System.exit() or otherwise). Move lf.lock() into the try-finally
block when saving the config file.

Delete .probe files on JVM shutdown -- they are created in daemon
threads that may terminate abruptly, not executing the "finally"
clause that normally removes these files.

Bug: 579445
Change-Id: Iaee2301eb14e6201406398a90228ad10cfea6098

HTTP Smart: set correct HTTP status on error

Previous behavior was that status code was automatically set to 200
regardless of reported status and according to HTTP Smart protocol[1]:

  If there is no repository at $GIT_URL, or the resource pointed to by
  a location matching $GIT_URL does not exist, the server MUST NOT
  respond with 200 OK response. A server SHOULD respond with
  404 Not Found, 410 Gone, or any other suitable HTTP status code which
  does not imply the resource exists as requested.

Since the jgit HTTP client isn't able to handle reading content from a
response reporting an error (calling HttpURLConnection#getInputStream
on a "failed" connection throws an exception and the internal interface
HttpConnection does not expose HttpURLConnection#getErrorStream) the
SmartClientSmartServerTest needed to be rewritten to expect the generic
response messages.

[1] https://git-scm.com/docs/http-protocol#_general_request_processing

Bug: 579676
Change-Id: Ibb942d02124a0bc279df09600b091354019ce064

Prepare 6.1.1-SNAPSHOT builds

Change-Id: Ifc80355025d8459245843be1c24dc5a286913e77

JGit v6.1.0.202203080745-r

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

[checkout] Use .gitattributes from the commit to be checked out

JGit used only one set of attributes constructed from the global and
info attributes, plus the attributes from working tree, index, and
HEAD.

These attributes must be used to determine whether the working tree is
dirty.

But for actually checking out a file, one must use the attributes from
global, info, and *the commit to be checked out*. Otherwise one may not
pick up definitions that are only in the .gitattributes of the commit
to be checked out or that are changed in that commit with respect to
the attributes currently in HEAD, the index, or the working tree.

Maintain in TreeWalk different Attributes per tree, and add operations
to determine EOL handling and smudge filters per tree.

Use the new methods in DirCacheCheckout and ResolveMerger. Note that
merging in JGit actually used the attributes from the base, not those
from ours, which looks dubious at least. It now uses those from ours,
and for checking out the ones from theirs.

The canBeContentMerged() determination was also done from the base
attributes, and is newly done from the ours attributes. Possibly this
should take into account all three attributes, and only if all three
agree the item can be content merged, a content merge should be
attempted? (What if the binary/text setting changes between base, ours,
or theirs?)

Also note that JGit attempts to perform content merges on non-binary
LFS files; there it used the filter attribute from base, too, even for
the ours and theirs versions. Newly it takes the filter attribute from
the correct tree. I'm not convinced doing content merges on potentially
huge files like LFS files is really a good idea.

Add tests in FilterCommandsTest and LfsGitTest to verify the behavior.

Open question: using index and working tree as fallback for the
attributes of ours (assuming it is HEAD) is OK. But does it also make
sense for base and theirs in merging?

Bug: 578707
Change-Id: I0bf433e9e3eb28479b6272e17c0666e175e67d08
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

Don't use final for method parameters

See https://wiki.eclipse.org/EGit/Contributor_Guide#Use_of_the_.22final.22_modifier

Change-Id: Idc6ed85483e381689e5085c4a1bacd75d26f5489

[push] support the "matching" RefSpecs ":" and "+:"

The implementation of push.default=matching was not correct.
It used the RefSpec "refs/heads/*:refs/heads/*", which would push
_all_ local branches. But "matching" must push only those local
branches for which a remote branch with the same name already exists
at the remote.

This RefSpec can be expanded only once the advertisement from the
remote has been received.

Enhance RefSpec so that ":" and "+:" can be represented. Introduce a
special RemoteRefUpdate for such a RefSpec; it must carry through the
fetch RefSpecs to be able to fill in the remote tracking updates as
needed. Implement the expansion in PushProcess.

Bug: 353405
Change-Id: I54a4bfbb0a6a7d77b9128bf4a9c951d6586c3df4
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

[push] Call the pre-push hook later in the push process

Call the pre-push hook only after having received the remote
advertisement and having determined rejections, like C git does.
Also similar to C git, don't pass rejected or up-to-date updates
to the pre-push hook.

Bug: 578852
Change-Id: I51d379ea7bd8234ec815f8f4a9fa325816f476cf
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

IndexDiff: use tree filter also for SubmoduleWalk

The only uses of IndexDiff.setFilter() in JGit and EGit set a path
filter. Passing the filter on to the SubmoduleWalk gives the desired
result, which is consistent with command-line git.

Bug: 565251
Change-Id: I8eca1ed73eb1d237b8785f369352f72af9e0e168
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

Run license check with option -Ddash.projectId=technology.jgit

This ensures that works-with-dependencies are attributed properly.

Change-Id: Ie41733cdecc83ae0b532fb4bd9f692bc09e16107

Exclude transitive dependencies of sshd-sftp

We don't need the dependencies of sshd-sftp to sshd-common and
sshd-core since they are contained in sshd-osgi.
Excluding them helps the dash IP log tool to not list them as required
dependencies of jgit.

Change-Id: I85bce4dca1b99ba880cf3e909fac9669c75e7854

Update DEPENDENCIES for 6.1.0 release

Change-Id: I9ea925bd444952dc204e2538b9d16fe631202e0c

Add dependency to dash-licenses

This is required to run the license check using the license tool [1]
required by the Eclipse project handbook [2]:

mvn org.eclipse.dash:license-tool-plugin:license-check -Ddash.summary=DEPENDENCIES

Note: the tool still requires Java 11 hence it needs to be run in a
separate build step and is not yet integrated in the build which runs
on Java 8.

[1] https://github.com/eclipse/dash-licenses
[2] https://www.eclipse.org/projects/handbook/#ip-license-tool

Change-Id: Ib41d54de246c3c9499cc3be9f026294c39fdfd99

Fix typos of some keys in LfsText

Change-Id: I86dee0b68e627e26cbd29976162bc7b953ebf276

Sort LfsText entries alphabetically

Change-Id: I3021cb246b51d861d51258808c75d5c6843ec82d

Support for "lfs.url" from ".lfsconfig"

- New class LfsConfig to enrich repository configuration by settings
from ".lfsconfig" file respecting configuration file precedence.
- Adapted LfsConnectionFactory to use LfsConfig instead of directly
using configuration from repository to calculate url of the lfs
repository

Bug: 578020
Change-Id: I156f4ec137c2e428136a2ca9b8a4011ecee2d915

Update Orbit to R20220302172233 for 2022-03

Change-Id: Ief504bf7f926d461e38186bf00711082d619fc08

Prepare 6.1.0-SNAPSHOT builds

Change-Id: I525fc1258a729c36d63fdb3c8170e9f04ad55cec

JGit v6.1.0.202203021511-rc1

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

Merge branch 'master' into stable-6.1

* master:
  Describe: add support for core.abbrev config option
  Add a typed config getter for integers confined to a range
  Remove odd prefix of PersonIdent test class
  PersonIdent: Add ctors that accept Instant in addition to Date
  Remove ignored potentiallyUnclosedCloseable check
  Make precedence more explicit
  [pgm] Add describe --abbrev option
  Cap describe abbrev option
  DescribeCommand: Add support for --abbrev=0

Change-Id: I1daa3501a38d57b628800fadb96b6b71eea8cbb3

Describe: add support for core.abbrev config option

If core.abbrev is unset or "auto" estimate abbreviation length like C
git does:
- Estimate repository's object count by only considering packed objects,
  round up to next power of 2
- With the order of 2^len objects, we expect a collision at 2^(len/2).
  But we also care about hex chars, not bits, and there are 4 bits per
  hex. So all together we need to divide by 2; but we also want to round
  odd numbers up, hence adding one before dividing.
- For small repos use at least 7 hexdigits
- If object database fails to determine object count use 7 hexdigits as
  fallback

If it is set to "no" do not abbreviate object-ids.

Otherwise set it to the configured value capped to the range between 4
and length of an unabbreviated object-id.

Change-Id: I425f9724b69813dbb57872466bf2d2e1d6dc72c6

Add a typed config getter for integers confined to a range

Use Integer#MIN_VALUE to denote unset option.

Change-Id: I4d65f2434013111f25520c0ed2b9a9dc8123c6cf

Remove odd prefix of PersonIdent test class

Change-Id: I05ede49902527c435691fb2c0f0d4da7ba077b7a

PersonIdent: Add ctors that accept Instant in addition to Date

Error Prone is flagging Date-API as obsolete and recommends to migrate
to Instant and LocalDate. Given that more JGit users starting to migrate
to new Time API, offer ctors that accept Instant type and also add new
getter that returns when attribute as Instant type.

Change-Id: I64a36bf40f191495c6889c1dff314ede06848880

Remove ignored potentiallyUnclosedCloseable check

potentiallyUnclosedCloseable currently is not checked and it creates
a warning when compiling with Maven.

Change-Id: I0715ead433270937f77f56a19aa203f8d6f5322f

Make precedence more explicit

Errorprone was failing the build with: "[OperatorPrecedence]. Use
grouping parenthesis to make the operator precedence explicit"

Add parentheses to silence it.

Change-Id: I81f1f249e38fd2543f5412b3501b0179d0759f55

[pgm] Add describe --abbrev option

Change-Id: I8adf2fad21db71b43266d3f274143eee6bc9dce2

Cap describe abbrev option

- minimum is 4 [1]
- maximum is length of a full ObjectId

[1] https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreabbrev

Change-Id: I145bde1a218f71b87b8d8260761dd0853770bb76

DescribeCommand: Add support for --abbrev=0

Setting --abbrev=0 suppresses long format and only shows the closest tag
[1].

[1] https://git-scm.com/docs/git-describe#Documentation/git-describe.txt---abbrevltngt

Change-Id: Ifcf4d7786dd0f0fb0315d8093fdb54384ed9d5f9

Prepare 6.1.0-SNAPSHOT builds

Change-Id: I30a89277373ad62c857151532942e135e34d1d0c

JGit v6.1.0.202202221755-m3

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