Merge branch 'master' into stable-6.9

* master:
  Introduce core.trustLooseRefStat config

Change-Id: I373138c4334d94b3e1e4335ee555b68f907d4c89

Prepare 6.9.0-SNAPSHOT builds

Change-Id: Ifadeead735c8772e58dd4e5c7381b44c5221a295

Introduce core.trustLooseRefStat config

With repositories on NFS, JGit can read an old value of a loose ref
or miss the existence of a loose ref if file attributes of the loose
ref or its parent directories are cached by NFS. Introduce a new config
'core.trustLooseRefStat' that will optionally refresh file attributes of
the loose ref (at least on some NFS clients).

Possible values for this new config are:

* always: Trust loose ref file attributes (default)
* after_open: Similar to 'always', but refresh the file attributes of
              the loose ref and its parent directories before trusting
              it

The default is set to always trust the file attributes as after_open is
known to degrade performance.

In a subsequent change, SnapshottingRefDirectory will be updated to
cache the directories that were refreshed to avoid duplicate work and
thereby improve performance to some extent for the after_open setting.

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

JGit v6.9.0.202402281855-rc1

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

Merge branch 'master' into stable-6.9

* master:
  Update SECURITY.md
  DfsObjDatabase: Let object database instantiate DfsPackFiles
  DfsPackFile: Abstract the bitmap loading to support other backends
  Remove unused API problem filters
  Support public key in IdentityFile
  Revert "StartGenerator: Fix parent rewrite with non-default RevFilter"
  DfsReader#getObjectSize: use size index if possible

Change-Id: I60244aec1e44fe5b757a9b7ccb320697e0dc9b29

Merge "Update SECURITY.md"

Update SECURITY.md

Use the text of the general Eclipse Vulnerability Reporting page at
https://www.eclipse.org/security.

Bug: jgit-31
Change-Id: I07dcf83199956e0173f958356661ade33252dab4

DfsObjDatabase: Let object database instantiate DfsPackFiles

DfsPackfile used to have only one constructor and it is invoked from 3
locations. Now we can construct DfsPackFiles with different bitmap
loaders, so it is helpful to concentrate the instantiation in one location.

Create DfsPackFile instances in the object database. This let
subclasses choose how to initialize those instances.

Change-Id: Ibb2ad86865154b6e7f0d5d26e8f533e0b5586246

DfsPackFile: Abstract the bitmap loading to support other backends

Current code reads the bitmap index from the pack extension and loads
all bitmaps into memory, with its IO and memory cost. We could
consider to store the bitmaps on e.g. a database and load them on
demand.

Abstract the loading of the PackBitmapIndex in an interface that can
be implemented with other backends.

Change-Id: Ib5f64d05954708ea5325feea7088a8df229b36a5

Remove unused API problem filters

Change-Id: I0d81fda5edde5348e765eebc39bd9293fba51e91

Merge "Support public key in IdentityFile"

Merge "DfsReader#getObjectSize: use size index if possible"

Support public key in IdentityFile

Public keys in the SSH configuration's "IdentityFile" are used for
example by Password Managers like KeePassXC
(https://keepassxc.org/docs/#faq-ssh-agent-auth-errors) or 1Password
(https://developer.1password.com/docs/ssh/agent/advanced/#match-key-with-host)
to match keys in the SSH agent with specific hosts.

Bug: jgit-25
Change-Id: I33d47057d9dd54d3d08ba5bb17f730435ac93dac

Merge "Revert "StartGenerator: Fix parent rewrite with non-default RevFilter""

Revert "StartGenerator: Fix parent rewrite with non-default RevFilter"

This reverts commit db5ce6b5c24408ae27eb6fa0b6289d51b129baeb.

Reason to revert: This change utilizes the RewriteGenerator even in
absence of a path, making the walk lengthy.

Change-Id: I5ffa6e8fead328191348c1e46828bf8c75ae1e42

Prepare 6.9.0-SNAPSHOT builds

Change-Id: I11f4871bfdf6c6c0de5d5ed577edf16bac8cf681

JGit v6.9.0.202402211805-m3

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

Merge branch 'stable-6.8'

* stable-6.8:
  Delete org.eclipse.jgit.ssh.apache.agent/bin/.project
  Allow to discover bitmap on disk created after the packfile

Change-Id: I08095dfaefb963876d993383cb35acc6b75d7691

Merge branch 'stable-6.7' into stable-6.8

* stable-6.7:
  Delete org.eclipse.jgit.ssh.apache.agent/bin/.project
  Allow to discover bitmap on disk created after the packfile

Change-Id: I01749bae6f46d1a8ebd25b890e667cc092f3a659

Merge branch 'stable-6.6' into stable-6.7

* stable-6.6:
  Delete org.eclipse.jgit.ssh.apache.agent/bin/.project
  Allow to discover bitmap on disk created after the packfile

Change-Id: I2bbc8c9a4ed45d37fa7ba63b2afd5511b6cf47a2

Delete org.eclipse.jgit.ssh.apache.agent/bin/.project

Change-Id: If2f50f81ffb8b5a1929b0ce403bff017ece29e2f

Allow to discover bitmap on disk created after the packfile

When the bitmap file was created *after* a packfile had been
loaded into the memory, JGit was unable to discover them.

That happed because of two problems:

1. The PackDirectory.getPacks() does not implement the usual
   while loop that is scanning through the packs directory
   as in the other parts of JGit.

2. The scan packs does not look for newly created bitmap files
   if the packfile is already loaded in memory.

Implement the normal packfiles scanning whenever the PackDirectory
needs to return a list of packs, and make sure that any reused
Pack object would have its associated bitmap properly refreshed
from disk.

Adapt the assertions in GcConcurrentTest with the rescanned list
of Pack from the objects/packs directory.

Bug: jgit-15
Change-Id: I2ed576cefd78a0e128b175228a59c9af51523d7b

DfsReader#getObjectSize: use size index if possible

getObjectSize reads the size from the first bytes of the object in the
pack, using IO. For blobs and depending on the configuration, the size
could be available in the object size index.

Try to get the size from the object size index if available. Read from
the pack otherwise.

Note that GC uses #getObjectSize from the existing pack to write the
next object size index.

Change-Id: Ia999290c06d061cb53aa8c0a2b28b1a9761567ef

Update jetty to 10.0.20

Change-Id: Ic79c5ce718fe1345f75c4254a9ee2aa7d91af359

Update maven plugins

- build-helper-maven-plugin to 3.5.0
- cyclonedx-maven-plugin to 2.7.11
- eclipse-jarsigner-plugin to 1.4.3
- git-commit-id-maven-plugin to 7.0.0
- japicmp-maven-plugin to 0.18.5
- maven-clean-plugin to 3.3.2
- maven-compiler-plugin to 3.12.1
- maven-enforcer-plugin to 3.4.1
- maven-jxr-plugin to 3.3.2<
- maven-site-plugin to 4.0.0-M13
- spotbugs-maven-plugin to 4.8.3.1
- tycho plugins to 4.0.6

Change-Id: Ie792f783b8b8453a37743f10f8c4162932e5ff85

Update org.assertj:assertj-core to 3.25.3

Change-Id: I3fd8adf3c1cc3f2c8826602b11d1d11fdfe29bfb

Update org.mockito:mockito-core to 5.10.0

Change-Id: I35dbb2402e65753e10bef4617b7e1683f9900406

Update org.apache.commons:commons-compress to 1.26.0

The new version now requires commons-io for the tests.
Hence adding dependency to commons-io:commons-io:2.15.1.

Change-Id: Ieb50ef559a119c89f90d700ab95a73c0fcae85a8

Update byte-buddy to 1.14.12

Change-Id: Idc56efd1ee6d9d1e039ccfffd5e16803b727f6dc

Add SystemReader.Delegate to reduce boiler-plate code needed to subclass

Original implementation by Han-Wen Nienhuys in Gerrit [1].

[1] https://gerrit-review.googlesource.com/c/gerrit/+/235169

Bug: jgit-24
Change-Id: I745f8c1c07de013a68168b91c2d9962d530d07bf

storage.file: Do not throw NSFE when deleting tmp files

If we try to delete a tmp file and it already doesn't exist, then
there's no problem and we don't need to throw an exception. This is
especially true for these existing cases using FileUtils.RETRY because
any missing files on retries are already considered successes. Not
throwing the exception quiets some logs and improves overall exception
handling.

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

FS.detectSymlinkSupport: fix a race

When multiple JGit clients are instantiated concurrently, they may try
to create the same symlink at the same time. When that happens, the
second thread will return an error (because the symlink already exists)
and that `FS` instance will think that symlinks are not supported,
causing havoc.

Change-Id: I362b933ff63a1471e3a5d70cc8c35eb2f25cc0dd
Signed-off-by: Motiejus Jakštys <motiejus@jakstys.lt>

Merge changes I8e577a23,Ic8e8b288

* changes:
  Errorprone EscapedEntity: Do not use HTML entities inside @code javadoc
  ChangedPathFilter: Suppress warning about backing array (errorprone)

Merge changes I9225d6a3,I9cf093ca,Id5a80635

* changes:
  RawParseUtils.nextLfSkippingSplitLines: fulfil contract as stated
  [gpg] Refactor the GpgSignatureVerifier
  RawParseUtils: utility method to get a header value

Merge branch 'stable-6.8' into master

* stable-6.8:
  RefDirectory: Do not unlock until after deleting loose ref
  Add missing javadoc description for declared exception
  SnapshottingRefDirectory: Invalidate snapshot after locking ref for update
  SnapshottingRefDir: Replace lambas with method refs
  SnapshottingRefDir: Reduce casts with overrides
  [errorprone] Fix wrong comparison which always evaluated to false
  [errorprone] Remove unnecessary comparison

Change-Id: I1d65c41292779dd5f8f46bc0adefbfc9a62ba2ce

Merge branch 'stable-6.7' into stable-6.8

* stable-6.7:
  RefDirectory: Do not unlock until after deleting loose ref
  Add missing javadoc description for declared exception
  SnapshottingRefDirectory: Invalidate snapshot after locking ref for update
  SnapshottingRefDir: Replace lambas with method refs
  SnapshottingRefDir: Reduce casts with overrides
  [errorprone] Fix wrong comparison which always evaluated to false
  [errorprone] Remove unnecessary comparison

Change-Id: Ic6312bd3b2b1db38a287ebc7f31062251341438a

Merge branch 'stable-6.6' into stable-6.7

* stable-6.6:
  RefDirectory: Do not unlock until after deleting loose ref
  Add missing javadoc description for declared exception
  SnapshottingRefDirectory: Invalidate snapshot after locking ref for update
  SnapshottingRefDir: Replace lambas with method refs
  SnapshottingRefDir: Reduce casts with overrides

Change-Id: Ic5f3c46e5557d0bd143694bd6020b67b6ec8f22e

RefDirectory: Do not unlock until after deleting loose ref

Fix a potential race condition where we would remove our loose ref lock
file before deleting the loose ref itself. This race could result in the
current thread deleting a loose ref newly written by another thread.

Other callers seem to be following the correct pattern, but improve the
method naming to try to help future callers.

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

Add missing javadoc description for declared exception

Change-Id: I16305bc15d2ddff1ce055772a711658ef81858e2

SnapshottingRefDirectory: Invalidate snapshot after locking ref for
update

When using the SnapshottingRefDirectory, if a thread has already read
packed-refs, then another actor updates packed-refs, the original
thread may create an update that is based on the old cached/snapshotted
packed-refs content. That update could effectively perform a forced
update unintentionally because it is unaware of the new content.

This seems particularly likely to happen in a scenario where a loose
ref was just packed. If the ref was loose, our thread would see the
current ref value (because we don't snapshot loose refs and always read
them from disk), but since there is no loose ref, we expect to find the
current value in packed-refs. However, (before this change) we rely
on our snapshot of packed-refs which does not contain the updated ref
value.

Invalidating the cache after the loose ref is locked ensures that the
ref value does not change again before we read it to perform the update.

Bug: jgit-21
Change-Id: Id10900a99bfd0401a1b9c39d997093af0289649e
Signed-off-by: Nasser Grainawi <quic_nasserg@quicinc.com>

SnapshottingRefDir: Replace lambas with method refs

Method references are shorter and easier to read in this case.

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

SnapshottingRefDir: Reduce casts with overrides

Overriding getRefDirectory() and getRefDatabase() lets us skip casting
to SnapshottingRefDirectory in several places.

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

[errorprone] Fix wrong comparison which always evaluated to false

org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/commitgraph/GraphObjectIndex.java:59:
error: [ComparisonOutOfRange] ints may have a value in the range
-2147483648 to 2147483647; therefore, this comparison to
Integer.MAX_VALUE will always evaluate to false
if (table[k] > Integer.MAX_VALUE) {
             ^

See https://errorprone.info/bugpattern/ComparisonOutOfRange

We need to check if variable `uint` of type `long` exceeds the maximum
possible int value before casting it to `int` below.

This was introduced in Ib5c0d6678cb242870a0f5841bd413ad3885e95f6

Change-Id: I675d594f523084be4c1678328cc343065e32d998
(cherry picked from commit 916200e278ebeaa2602b5dc23143c8eedf11858b)

[errorprone] Remove unnecessary comparison

Raised by errorprone:

org.eclipse.jgit/src/org/eclipse/jgit/lib/CommitConfig.java:406: error:
[ComparisonOutOfRange] chars may have a value in the range 0 to 65535;
therefore, this comparison to 0 will always evaluate to true
if (ch >= 0 && ch < inUse.length) {
       ^
see https://errorprone.info/bugpattern/ComparisonOutOfRange

Change-Id: I9625aa7894a34dbffd77d39a40c6e285c86b56d5
(cherry picked from commit cf5ec856bda907c0537ce5a80246b9ab18195c8b)

Merge branch 'stable-6.8' into master

* stable-6.8:
  Improve handling of NFS stale handle errors
  Fix handling of missing pack index file
  Add tests for handling pack files removal during fetch

Change-Id: Icae170f85d71e65c308078648ae85dfc8308176d

Merge branch 'stable-6.7' into stable-6.8

* stable-6.7:
  Improve handling of NFS stale handle errors
  Fix handling of missing pack index file
  Add tests for handling pack files removal during fetch

Change-Id: I409d1dc3354ad65c048d2c40f39071a1207246c6

Merge branch 'stable-6.6' into stable-6.7

* stable-6.6:
  Improve handling of NFS stale handle errors
  Fix handling of missing pack index file
  Add tests for handling pack files removal during fetch

Change-Id: Ie00984319d68beeffcbdb6bb323fbeb94a118e5c

Errorprone EscapedEntity: Do not use HTML entities inside @code javadoc

Change-Id: I8e577a23e7fbe22a3024ad62144e7f19eec465c3

ChangedPathFilter: Suppress warning about backing array (errorprone)

Errorprone warns about direct access to the underlying array.

That is the intention of this code, and those ByteBuffers are created
with ByteBuffer#wrap() so it should be safe.

Change-Id: Ic8e8b288f08ac794cf7f09dfccfefcba0a4685bf

PackWriterBitmapPreparer: Do not generate bitmaps for excessive branch tips.

In https://review.gerrithub.io/c/eclipse-jgit/jgit/+/1174407, I changed the bitmap selection algorithm to cap the number of branches included in the bitmap.

There was a bug in that change. When the selection algorithm iterates
over the commits in a branch B, it automatically includes a bitmap for
the tip of any other branch C that happens to be on B. So even though we never iterated over C, we would still index the tip commit of C.

Keep a list of the "excessive" branch tips and check that the commit is not in there before generating a bitmap. We only skip tips that would be selected as a result of being a tip.  If it would be selected for some other reason (e.g. it is one of the first 100 commits in master) then it is not skipped.

Change-Id: Ic8b4f82e816eac649a47c8918a41ed4ff0d877cd

Don't use localized String during JVM shutdown

During shutdown the JGitText class may already be unloaded causing
NoClassDefFoundError.

Bug: jgit-17
Change-Id: I657b5a508efc8b3778be346d640f4e4d69abd5c5

RawParseUtils.nextLfSkippingSplitLines: fulfil contract as stated

If there is no newline after the last header, the method is supposed to
return the buffer length, but it returned buffer.length - 1.

Change-Id: I9225d6a35a002244c246bc8781ceaf4369fb9a60

[gpg] Refactor the GpgSignatureVerifier

Add a new method verify(GpgConfig, byte[], byte[]) and deprecate the
existing verify(byte[], byte[]). Some implementations of the interface
may need the GpgConfig.

Factor out extracting the raw armored signature from commits or tags
into an abstract AbstractGpgSignatureVerifier class so that different
implementations don't have to re-implement that bit. Call the new verify
method, passing along the GpgConfig.

This makes the GPG interfaces more versatile and facilitates
implementing an alternate GpgSignatureVerifier.

Change-Id: I9cf093caa9fdebede801d665f2591cd9b275e1fd

RawParseUtils: utility method to get a header value

The new method takes care of removing the leading blanks on continuation
lines in multi-line headers.

Change-Id: Id5a8063512a2abc3177c104d6ba8fa50d0dc6352

Improve handling of NFS stale handle errors

Mark packfile as invalid when NFS stale handle error occurs.

This should fix broken fetch operations when the repo is located on the
NFS system and is GC'ed on a separate system (or process). Which may
result in the index, pack or bitmap file being removed when they are
accessed from the fetch operation.

Bug: 573770
Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com>
Change-Id: I70217bfb93bf7421ea2c1d74cbe4f15c76d9c098
(cherry picked from commit c701c01b49d92993f1c3df0a0e26a2dd68b8cec1)

Fix handling of missing pack index file

As demonstrated in
`UploadPackHandleDeletedPackFile.testV2IdxFileRemovedDuringUploadPack`
the fetch operation will fail when the pack index file is removed.

This is due to a wrapping of `FileNotFoundException` (which is a
subclass of `IOExeption`) in an `IOException` at PackIndex L#68. This
is then changing the behaviour of error handling in
`Pack.file.getBitmapIndex()` where the `FileNotFoundException` is
swallowed and allows the fetch process to continue. With FNFE being
wrapped in IOE, this blows up and breaks the fetch operation.

Simply rethrowing `FileNotFoundException` from `PackFile.open()` fixes
the broken fetch operation. This will also mark the whole pack as
invalid in the `IOException` handler in `Pack.idx()` method.

Change-Id: Ibe321aa1af21d26500e1cb2eb3464cc99a6dbc62
Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com>
(cherry picked from commit e0910eda3ea1c474b4cf9b00ac698f739a982f8c)

Add tests for handling pack files removal during fetch

Although this could sound like a corner case, it really can occur out
there in the real world. Especially in the Gerrit world where the
repositories could be GC'ed on a separate process or system.

The `FileNotFoundException` seems to be handled correctly in
`PackFile#doOpen` (line 671) and it will mark the pack as invalid. But
triggering that code path was not an easy task.

First of all, we need to add a new commit to the `master` branch of the
test repository after `UploadPack` object is created.

Secondly, in the refspec for fetch, commit id instead of "regular"
refspec must be used.

With both in place, we can see a warning log statement about deleted
pack file. And the fetch succeeds!

Also, tests for the removal of *.idx and *.bitmap files were added.

This unveiled a corner for the *.idx file deletion while fetching, as
the test will fail with "Unreachable pack index" IOException only
when the HEAD commit is empty.

Change-Id: If26c83f9b12993d1ab7d6bad6bd863c29520b062
Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com>
(cherry picked from commit ba5adc4ce6f234cb300b0f73a1efdba9bba1b5d8)

RebaseCommand: fix stopping on root commit conflicts

If rebasing runs into a conflict when applying a root commit from an
independent branch, there is no parent commit. Write an empty patch
file in that case like C git does.

Bug: jgit-6
Change-Id: I315313673d2abf29639d7d96c958d599961ba276
Signed-off-by: Thomas Wolf <twolf@apache.org>

Improve handling of NFS stale handle errors

Mark packfile as invalid when NFS stale handle error occurs.

This should fix broken fetch operations when the repo is located on the
NFS system and is GC'ed on a separate system (or process). Which may
result in the index, pack or bitmap file being removed when they are
accessed from the fetch operation.

Bug: 573770
Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com>
Change-Id: I70217bfb93bf7421ea2c1d74cbe4f15c76d9c098

Fix handling of missing pack index file

As demonstrated in
`UploadPackHandleDeletedPackFile.testV2IdxFileRemovedDuringUploadPack`
the fetch operation will fail when the pack index file is removed.

This is due to a wrapping of `FileNotFoundException` (which is a
subclass of `IOExeption`) in an `IOException` at PackIndex L#68. This
is then changing the behaviour of error handling in
`Pack.file.getBitmapIndex()` where the `FileNotFoundException` is
swallowed and allows the fetch process to continue. With FNFE being
wrapped in IOE, this blows up and breaks the fetch operation.

Simply rethrowing `FileNotFoundException` from `PackFile.open()` fixes
the broken fetch operation. This will also mark the whole pack as
invalid in the `IOException` handler in `Pack.idx()` method.

Change-Id: Ibe321aa1af21d26500e1cb2eb3464cc99a6dbc62
Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com>

CherryPick: add ability to customise cherry-picked commit message

Originally I wanted to support a feature similar to `-x` options from
https://git-scm.com/docs/git-cherry-pick#_options.
The idea was to append original commit hash in this format:
```
my original commit message

(cherry picked from commit 75355897dc28e9975afed028c1a6d8c6b97b2a3c)
```
This can be useful information in some integrations.
I decided to make it in a more generic way
and pass custom `CherryPickCommitMessageProvider` implementation.
One of the two default implementations can append original commit hash

Change-Id: Id664e8438b0b76c5cb9b58113887eec04aa6f611

RawParseUtils: Add missing @since tag for new API method

This method was introduced in 8116f66b9c.

Change-Id: Ifd3341a03464a1d7164c176cf3a6cf83f45a2747

Silence API warning for new constant

and remove unused API problem filters.

Change-Id: Ia6f4fcc98b786e3e4b65f9e42cc60bbf6ca7c289

[ssh] Bump Apache MINA sshd 2.11.0 -> 2.12.0

This includes the upstream fix for CVE-2023-48795[1] ("strict KEX"
protocol extension mitigating the "Terrapin attack"[2]) in JGit.

[1] https://nvd.nist.gov/vuln/detail/CVE-2023-48795
[2] https://www.terrapin-attack.com/

Bug: jgit-16
Change-Id: Ie9aa5b903ea6795bd1511afea0bebdb537b56148
Signed-off-by: Thomas Wolf <twolf@apache.org>

Merge branch 'stable-6.8'

* stable-6.8:
  Introduce a PriorityQueue sorting RevCommits by commit timestamp
  Remove org.eclipse.jgit.benchmark/.factorypath
  Update jmh to 1.37 for org.eclipse.jgit.benchmark

Change-Id: Ifdd88eed34be3a1f4897b468392fd86bbc3f3a64

Merge branch 'stable-6.7' into stable-6.8

* stable-6.7:
  Introduce a PriorityQueue sorting RevCommits by commit timestamp
  Remove org.eclipse.jgit.benchmark/.factorypath
  Update jmh to 1.37 for org.eclipse.jgit.benchmark

Change-Id: I5d49a9dc7da17b83243229d4d8d3b9ee0a063e65

Merge branch 'stable-6.6' into stable-6.7

* stable-6.6:
  Introduce a PriorityQueue sorting RevCommits by commit timestamp
  Remove org.eclipse.jgit.benchmark/.factorypath
  Update jmh to 1.37 for org.eclipse.jgit.benchmark

Change-Id: I76ebca527e523f124bfe81c821169c790eddccb6

Introduce a PriorityQueue sorting RevCommits by commit timestamp

The DateRevQueue uses a tailor-made algorithm to keep
RevCommits sorted by reversed commit timestamp, which has a O(n*n/2)
complexity and caused the explosion of the Git fetch times to
tens of seconds.

The standard Java PriorityQueue provides a O(n*log(n)) complexity
and scales much better with the increase of the number of
RevCommits.

Introduce a new implementation DateRevPriorityQueue of the DateRevQueue
based on PriorityQueue.

Enable usage of the new DateRevPriorityQueue implementation by setting
the system property REVWALK_USE_PRIORITY_QUEUE=true. By default the old
implementation DateRevQueue is used.

Benchmark results:
```
(numCommits)  (usePriorityQueue)  Mode  Cnt     Score Error  Units
           5                true  avgt   10    39,4 ±   6,1  ns/op
           5               false  avgt   10    14,1 ±   2,2  ns/op
          10                true  avgt   10    29,7 ±   3,5  ns/op
          10               false  avgt   10    13,2 ±   2,0  ns/op
          50                true  avgt   10    50,4 ±   5,3  ns/op
          50               false  avgt   10    18,6 ±   0,2  ns/op
         100                true  avgt   10    58,3 ±   5,0  ns/op
         100               false  avgt   10    20,5 ±   0,8  ns/op
         500                true  avgt   10    51,7 ±   2,6  ns/op
         500               false  avgt   10    43,3 ±   0,5  ns/op
        1000                true  avgt   10    49,2 ±   2,4  ns/op
        1000               false  avgt   10    62,7 ±   0,2  ns/op
        5000                true  avgt   10    48,8 ±   1,5  ns/op
        5000               false  avgt   10   228,3 ±   0,5  ns/op
       10000                true  avgt   10    44,2 ±   0,9  ns/op
       10000               false  avgt   10   377,6 ±   2,7  ns/op
       50000                true  avgt   10    50,3 ±   1,6  ns/op
       50000               false  avgt   10   637,0 ± 111,8  ns/op
      100000                true  avgt   10    61,8 ±   4,4  ns/op
      100000               false  avgt   10   965,1 ± 268,0  ns/op
      500000                true  avgt   10   127,2 ±   7,9  ns/op
      500000               false  avgt   10  9610,2 ± 184,8  ns/op
```

Memory allocation results:
```
Number of commits loaded: 850 000
Custom implementation: 378 245 120 Bytes
Priority queue implementation: 340 495 616 Bytes
```

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

Remove org.eclipse.jgit.benchmark/.factorypath

it's outdated and seems to be unused.

Change-Id: I4ac0f6d6427ee9f76a59296e991e4e03b25bcf05

Update jmh to 1.37 for org.eclipse.jgit.benchmark

and
- fix org.eclipse.jgit.benchmark/.classpath

Change-Id: I66f81228f17ede5732fa43aa693b4cfddb5a71f6

Add tests for handling pack files removal during fetch

Although this could sound like a corner case, it really can occur out
there in the real world. Especially in the Gerrit world where the
repositories could be GC'ed on a separate process or system.

The `FileNotFoundException` seems to be handled correctly in
`PackFile#doOpen` (line 671) and it will mark the pack as invalid. But
triggering that code path was not an easy task.

First of all, we need to add a new commit to the `master` branch of the
test repository after `UploadPack` object is created.

Secondly, in the refspec for fetch, commit id instead of "regular"
refspec must be used.

With both in place, we can see a warning log statement about deleted
pack file. And the fetch succeeds!

Also, tests for the removal of *.idx and *.bitmap files were added.

This unveiled a corner for the *.idx file deletion while fetching, as
the test will fail with "Unreachable pack index" IOException only
when the HEAD commit is empty.

Change-Id: If26c83f9b12993d1ab7d6bad6bd863c29520b062
Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com>

Merge "Remove invalid/unnecessary Maven settings"

Merge "PackWriterBitmapPreparer: Set limit on excessive branch count"

PackWriterBitmapPreparer: Set limit on excessive branch count

If there are too many branches then the bitmap
indexing selects only the tip commits of the least active
branches to reduce the amount of bitmaps to load on request.
This can still be a problem if the number of inactive branches
rival or exceed the total number of commits selected
for the active branches.

Limit the number of branches that receive only-tip bitmaps.
This reduces the memory pressure of loading all the bitmaps,
and allows us to model the size of the bitmap index without
considering the number of branches.

Bitmaps are generated for branches in order of most recent commit,
and follow these rules:

* The first {@code DEFAULT_BITMAP_EXCESSIVE_BRANCH_COUNT} most active
  branches have full bitmap coverage.
* The {@code DEFAULT_BITMAP_EXCESSIVE_BRANCH_COUNT} to {@code
  DEFAULT_BITMAP_EXCESSIVE_BRANCH_TIP_COUNT} most active branches have
  only the tip commit covered.
* The remaining branches have no bitmap coverage.

To prevent effecting existing repositories, the default value is set
at Integer.MAX_VALUE.

Change-Id: I7cc53c898cdc04953b95669be0b069543e10c6f8

Update jna to 5.14.0

Change-Id: Ie60f618fabd1c35815a7fe2775b7fe059baba8b4

Merge "DfsInserter/PackParser: keep min size for index in the inserter"

DfsInserter/PackParser: keep min size for index in the inserter

Both, inserter and packparser read the minimum size for the object
size index. The writing is invoked from both classes but done only by
the inserter.

Let the inserter read and handle the conf. Do this in the constructor
and allow override so some paths can hardcode a value.

Change-Id: I890cadd29678a53738761f4b0ab13020d6353f3e

Merge branch 'stable-6.8'

* stable-6.8:
  Silence API warnings
  Make sure ref to prune is in packed refs
  Checkout: better directory handling

Change-Id: Ief6e4d6cd3fcea327f28c32643b8323f5d0c6936

Merge branch 'stable-6.7' into stable-6.8

* stable-6.7:
  Silence API warnings
  Make sure ref to prune is in packed refs
  Checkout: better directory handling

Change-Id: Ie8c433e14d025055aa6ce674d6d1220fe1354785

Merge branch 'stable-6.6' into stable-6.7

* stable-6.6:
  Silence API warnings
  Make sure ref to prune is in packed refs
  Checkout: better directory handling

Change-Id: Id3b01c7a583d45b4e67e3f993006a5646f77a41d

Merge branch 'stable-6.5' into stable-6.6

* stable-6.5:
  Checkout: better directory handling

Change-Id: I1712191514b8c1b9ea048974376a6765ff7970c7

Merge branch 'stable-6.4' into stable-6.5

* stable-6.4:
  Checkout: better directory handling

Change-Id: I68e11fb06a354961f4146de51d326b69be5b69d3

Merge branch 'stable-6.3' into stable-6.4

* stable-6.3:
  Checkout: better directory handling

Change-Id: Ie0fefa8afc07f638ee05a46d272db7b7b0f8d464

Merge branch 'stable-6.2' into stable-6.3

* stable-6.2:
  Checkout: better directory handling

Change-Id: Id27612578f822cabc1a38ad1f8e859ae354045a9

Merge branch 'stable-6.1' into stable-6.2

* stable-6.1:
  Checkout: better directory handling

Change-Id: I2f8e5410f4962d38bc6e822b5cda42df68aef32b

Merge branch 'stable-6.0' into stable-6.1

* stable-6.0:
  Checkout: better directory handling

Change-Id: Ide9fb318b5fe413d73d73a19943c6dacdcf07f3d

Merge branch 'stable-5.13' into stable-6.0

* stable-5.13:
  Checkout: better directory handling

Revert commit 170244d05977491271a1cc234583d2e5ba75145d
"Checkout: better directory handling" which is the downport of the
original fix Ie12864c54c9f901a2ccee7caddec73027f353111 which was done
on stable-6.6. Merging this up to stable-6.6 would be a lot of work and
these branches aren't maintained anymore hence revert this change here.
This way the fix is available on stable-5.13 for those who still need
Java 8 and everybody else should upgrade to 6.6.1 or higher.

Change-Id: Iffe50a5e62c6655814265d9cc6c5c2996baa1a31

Merge "FooterLines: handle extraction from messages without headers"

FooterLines: handle extraction from messages without headers

Prior to this change, long subjects of messages with no headers were
treated as headers, and therefore were skipped. In a message of the
form `<long subject>\n\n<footers>`, the footers would then get parsed
as a message, meaning no footers were returned.

After this change, the first lines are skipped only if they match any
of the known headers. The first line ofter the optional headers is then
assumed to be the subject line.

`FooterLineTest` had a few test cases for extracting footers from
messages with no headers. However, there were all with short messages,
so the "skip this line" logic in `RawParseUtils` was never triggered.
Added test case to catch this issue.

Change-Id: I971a1dddf1a9aea094360c3c8fc3b9a8b011bbf9
Issue: Google b/287891316

Silence API warnings

Change-Id: I44084c45ed2c5e642021d1de4f37af769e4b317f

Remove invalid/unnecessary Maven settings

* Remove jgit.target POM and remove it from the module list. This was
only necessary when the target file had to be referenced as an artifact.
Meanwhile we reference it directly by its path, and can remove the Maven
build around it.

* Remove tycho configuration options that are no longer valid (resolved
was removed very early, probably before 1.0; includePackedArtifacts was
removed in 3.0). Also remove duplicate version specification.

Change-Id: Ifa69065dd73bf586b8359541375e065f5f60aa03

Update maven plugins

- com.github.siom79.japicmp:japicmp-maven-plugin to 0.18.3
- com.github.spotbugs:spotbugs-maven-plugin to 4.8.2.0
- io.github.git-commit-id:git-commit-id-maven-plugin to 7.0.0
- org.apache.maven.plugins:maven-clean-plugin to 3.3.2
- org.apache.maven.plugins:maven-compiler-plugin to 3.12.0
- org.apache.maven.plugins:maven-dependency-plugin to 3.6.1
- org.apache.maven.plugins:maven-enforcer-plugin to 3.4.1
- org.apache.maven.plugins:maven-javadoc-plugin to 3.6.3
- org.apache.maven.plugins:maven-jxr-plugin to 3.3.1
- org.apache.maven.plugins:maven-pmd-plugin to 3.21.2
- org.apache.maven.plugins:maven-project-info-reports-plugin to 3.5.1
- org.apache.maven.plugins:maven-shade-plugin to 3.5.1
- org.apache.maven.plugins:maven-site-plugin to 4.0.0-M13
- org.apache.maven.plugins:maven-surefire-plugin to 3.2.3
- org.codehaus.mojo:build-helper-maven-plugin to 3.5.0
- org.cyclonedx:cyclonedx-maven-plugin to 2.7.10
- org.eclipse.cbi.maven.plugins:eclipse-jarsigner-plugin to 1.4.3
- org.jacoco:jacoco-maven-plugin to 0.8.11

Change-Id: Ie146085f567f0bcfe0124627939382fe5a764e6c

Update org.eclipse.dash:license-tool-plugin to 1.1.0

Change-Id: I039e10fc6790d54c30cfd85a53c05604351996e0

Enable using slf4j 2.x

Eclipse platform moved to sfl4j 2.x. Hence relax version constraint so
that both 1.7 and 2.x are allowed.

Bug: egit-5
Change-Id: Ie0b00310d8f3f2553457c8668a38978a67b8febe

Update Tycho to 4.0.4

Change-Id: I9d087b5a62ab3d474d894a2276572156c14dad4e

Update mockito to 5.8.0

Change-Id: I70d33b7af25fcb4754fb048dd9054eef7356f00c

Add 4.31 target platform and update orbit to 4.31

and update bytebuddy to 1.14.10.

Change-Id: I145776a31d806f7e6dcc90263650109b3eb19067

Update ecj to 3.36.0

Change-Id: I803de19e8086239ebbae9877121946fdddfbaa89

Renormalize line endings based on .gitattributes

This fixes line endings of all text files to use LF in the repository.

Change-Id: I4df6fd7aaf9db9cdaa953a0d1062981b4612056c

Configure .gitattributes to manage line endings

Mark test resources as binary to prevent line ending normalization
Some of the test resources are used to test handling of line endings
in JGit.

Change-Id: Idd9ba604945797d1cd1f3af1a1987aee3188e1d6