summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Update byte-buddy to 1.14.12Matthias Sohn2024-02-2018-51/+51
| | | | Change-Id: Idc56efd1ee6d9d1e039ccfffd5e16803b727f6dc
* Add SystemReader.Delegate to reduce boiler-plate code needed to subclassMatthias Sohn2024-02-201-0/+61
| | | | | | | | | 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 filesNasser Grainawi2024-02-194-8/+8
| | | | | | | | | | | | 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 raceMotiejus Jakštys2024-02-192-1/+22
| | | | | | | | | | | 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,Ic8e8b288Matthias Sohn2024-02-193-3/+4
|\ | | | | | | | | | | * changes: Errorprone EscapedEntity: Do not use HTML entities inside @code javadoc ChangedPathFilter: Suppress warning about backing array (errorprone)
| * Errorprone EscapedEntity: Do not use HTML entities inside @code javadocIvan Frade2024-02-092-3/+3
| | | | | | | | Change-Id: I8e577a23e7fbe22a3024ad62144e7f19eec465c3
| * ChangedPathFilter: Suppress warning about backing array (errorprone)Ivan Frade2024-02-091-0/+1
| | | | | | | | | | | | | | | | | | 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
* | Merge changes I9225d6a3,I9cf093ca,Id5a80635Matthias Sohn2024-02-197-63/+204
|\ \ | | | | | | | | | | | | | | | | | | * changes: RawParseUtils.nextLfSkippingSplitLines: fulfil contract as stated [gpg] Refactor the GpgSignatureVerifier RawParseUtils: utility method to get a header value
| * | RawParseUtils.nextLfSkippingSplitLines: fulfil contract as statedThomas Wolf2024-02-012-1/+11
| | | | | | | | | | | | | | | | | | | | | 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 GpgSignatureVerifierThomas Wolf2024-02-014-54/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 valueThomas Wolf2024-02-013-8/+74
| |/ | | | | | | | | | | | | The new method takes care of removing the leading blanks on continuation lines in multi-line headers. Change-Id: Id5a8063512a2abc3177c104d6ba8fa50d0dc6352
* | Merge branch 'stable-6.8' into masterDariusz Luksza2024-02-153-26/+80
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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.8Dariusz Luksza2024-02-153-26/+80
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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.7Dariusz Luksza2024-02-153-26/+80
| | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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 refNasser Grainawi2024-02-131-9/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 exceptionMatthias Sohn2024-02-131-0/+1
| | | | | | | | | | | | | | | | | | | | Change-Id: I16305bc15d2ddff1ce055772a711658ef81858e2
| | | * | SnapshottingRefDirectory: Invalidate snapshot after locking ref forNasser Grainawi2024-02-132-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 refsNasser Grainawi2024-02-131-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 overridesNasser Grainawi2024-02-131-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 falseMatthias Sohn2024-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 comparisonMatthias Sohn2024-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 masterDariusz Luksza2024-02-120-0/+0
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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.8Dariusz Luksza2024-02-123-5/+169
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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.7Dariusz Luksza2024-02-123-5/+169
| | |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| | | * | Improve handling of NFS stale handle errorsDariusz Luksza2024-01-291-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 fileDariusz Luksza2024-01-293-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 fetchDariusz Luksza2024-01-291-0/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | | | | PackWriterBitmapPreparer: Do not generate bitmaps for excessive branch tips.jackdt@google.com2024-02-071-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 shutdownMatthias Sohn2024-02-063-3/+3
| |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | During shutdown the JGitText class may already be unloaded causing NoClassDefFoundError. Bug: jgit-17 Change-Id: I657b5a508efc8b3778be346d640f4e4d69abd5c5
* | | | RebaseCommand: fix stopping on root commit conflictsThomas Wolf2024-01-282-5/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 errorsDariusz Luksza2024-01-281-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 fileDariusz Luksza2024-01-283-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 messageDmitrii Naumenko2024-01-285-1/+309
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 methodMatthias Sohn2024-01-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | This method was introduced in 8116f66b9c. Change-Id: Ifd3341a03464a1d7164c176cf3a6cf83f45a2747
* | | | Silence API warning for new constantMatthias Sohn2024-01-231-19/+1
| | | | | | | | | | | | | | | | | | | | | | | | and remove unused API problem filters. Change-Id: Ia6f4fcc98b786e3e4b65f9e42cc60bbf6ca7c289
* | | | [ssh] Bump Apache MINA sshd 2.11.0 -> 2.12.0Thomas Wolf2024-01-2021-141/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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'Matthias Sohn2024-01-2011-40/+448
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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.8Matthias Sohn2024-01-2011-41/+449
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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.7Matthias Sohn2024-01-2013-87/+463
| | |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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 timestampLuca Milanesio2024-01-1910-17/+449
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/.factorypathMatthias Sohn2024-01-191-29/+0
| | | | | | | | | | | | | | | | | | | | | | | | it's outdated and seems to be unused. Change-Id: I4ac0f6d6427ee9f76a59296e991e4e03b25bcf05
| | | * Update jmh to 1.37 for org.eclipse.jgit.benchmarkMatthias Sohn2024-01-193-17/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | and - fix org.eclipse.jgit.benchmark/.classpath Change-Id: I66f81228f17ede5732fa43aa693b4cfddb5a71f6
* | | | Add tests for handling pack files removal during fetchDariusz Luksza2024-01-181-0/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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"Matthias Sohn2024-01-163-42/+0
|\ \ \ \
| * | | | Remove invalid/unnecessary Maven settingsMichael Keppler2023-12-233-42/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
* | | | | Merge "PackWriterBitmapPreparer: Set limit on excessive branch count"Ivan Frade2024-01-123-5/+88
|\ \ \ \ \
| * | | | | PackWriterBitmapPreparer: Set limit on excessive branch countJackson Toeniskoetter2024-01-123-5/+88
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.0Matthias Sohn2024-01-1218-52/+54
| | | | | | | | | | | | | | | | | | | | Change-Id: Ie60f618fabd1c35815a7fe2775b7fe059baba8b4
* | | | | Merge "DfsInserter/PackParser: keep min size for index in the inserter"Ivan Frade2024-01-112-13/+26
|\ \ \ \ \
| * | | | | DfsInserter/PackParser: keep min size for index in the inserterIvan Frade2024-01-112-13/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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