summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test
Commit message (Collapse)AuthorAgeFilesLines
* JGit v6.9.0.202403050045-rv6.9.0.202403050045-rMatthias Sohn2024-03-052-2/+2
| | | | | Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Change-Id: I4c7a6542ad4252c5a9499e69f68650d2026bde40
* Prepare 6.9.0-SNAPSHOT buildsMatthias Sohn2024-03-052-2/+2
| | | | Change-Id: Ifadeead735c8772e58dd4e5c7381b44c5221a295
* JGit v6.9.0.202402281855-rc1v6.9.0.202402281855-rc1Matthias Sohn2024-02-282-2/+2
| | | | | Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Change-Id: I23d489ccdc257a8c25da4b90dc51d4a8951d320c
* DfsPackFile: Abstract the bitmap loading to support other backendsIvan Frade2024-02-261-0/+41
| | | | | | | | | | | | 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
* Merge "DfsReader#getObjectSize: use size index if possible"Ivan Frade2024-02-231-29/+88
|\
| * DfsReader#getObjectSize: use size index if possibleIvan Frade2024-02-201-29/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Revert "StartGenerator: Fix parent rewrite with non-default RevFilter""Ivan Frade2024-02-222-113/+0
|\ \
| * | Revert "StartGenerator: Fix parent rewrite with non-default RevFilter"Ivan Frade2024-02-212-113/+0
| |/ | | | | | | | | | | | | | | | | 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
* | Merge branch 'stable-6.8'Matthias Sohn2024-02-211-6/+5
|\ \ | |/ |/| | | | | | | | | | | * 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.8Matthias Sohn2024-02-211-6/+5
| |\ | | | | | | | | | | | | | | | | | | | | | * 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.7Matthias Sohn2024-02-211-6/+5
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| | | * Allow to discover bitmap on disk created after the packfileLuca Milanesio2024-02-201-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | Merge branch 'stable-6.7' into stable-6.8Dariusz Luksza2024-02-121-0/+146
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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-121-0/+146
| | |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| | | * Fix handling of missing pack index fileDariusz Luksza2024-01-291-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | | | Update org.apache.commons:commons-compress to 1.26.0Matthias Sohn2024-02-202-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The new version now requires commons-io for the tests. Hence adding dependency to commons-io:commons-io:2.15.1. Change-Id: Ieb50ef559a119c89f90d700ab95a73c0fcae85a8
* | | | FS.detectSymlinkSupport: fix a raceMotiejus Jakštys2024-02-191-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | RawParseUtils.nextLfSkippingSplitLines: fulfil contract as statedThomas Wolf2024-02-011-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | RawParseUtils: utility method to get a header valueThomas Wolf2024-02-011-6/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The new method takes care of removing the leading blanks on continuation lines in multi-line headers. Change-Id: Id5a8063512a2abc3177c104d6ba8fa50d0dc6352
* | | | RebaseCommand: fix stopping on root commit conflictsThomas Wolf2024-01-281-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | Fix handling of missing pack index fileDariusz Luksza2024-01-281-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-282-0/+193
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | Merge branch 'stable-6.8'Matthias Sohn2024-01-202-1/+110
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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-202-1/+110
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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-202-1/+110
| | |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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-192-1/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | 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 "FooterLines: handle extraction from messages without headers"Ivan Frade2024-01-091-0/+9
|\ \ \ \
| * | | | FooterLines: handle extraction from messages without headersNitzan Gur-Furman2024-01-091-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | | Enable using slf4j 2.xMatthias Sohn2023-12-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | | PackBitmapIndex/StoredBitmap: Expose size and countsIvan Frade2023-12-142-0/+166
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PackBitmapIndex holds a collection of StoredBitmaps. StoredBitmaps can be either base bitmaps (ready) or an XOR over another bitmap. XOR bitmaps are replaced with a resolved version on demand. Bitmaps can use a significant amount of memory but we don't have detailed visibility about it. Add methods to PackBitmapIndex to know how many xor/bases we have and their sizes. Change-Id: I57aa80a1f07ddf9223eb34cfda85aab85529ea9c
* | | | FooterLine: Protect from ill-formed messageKamil Musin2023-12-051-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A raw commit message has some headers and then the actual message. RawParseUtils.commitMessage returns the start position of the actual message, or -1 when the message is not raw. FooterLine is not handling this -1 and throws an IndexOutOfBounds exception. Consider than msgB can be -1 when looking for the beginning of the last paragraph. FooterLine javadoc and parameter talk only about "raw" but previous code accepted non-raw messages (used mostly in unit tests) so we need to keep this behavior. Change-Id: I4b88c507e210fdd200a85b01665c8524ab393b00
* | | | StartGenerator: Fix parent rewrite with non-default RevFilterRonald Bhuleskar2023-12-042-0/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | StartGenerator is responsible for propagating the RevWalk's parent rewrite setting, but it currently only does so when a non-default TreeFilter is set, when it should also do so if the default TreeFilter is used with a non-default RevFilter. Adding a new if condition within StartGenerator to enable parent rewrite with non-default RevFilter. TreeRevFilter relied on the old buggy functionality and has been modified to explicitly refrain from rewriting parents. Change-Id: I4e4ff67fb279edbcc3461496b132cea774fb742f
* | | | Prepare 6.9.0-SNAPSHOT buildsMatthias Sohn2023-12-042-60/+60
| | | | | | | | | | | | | | | | Change-Id: Id1d784ec4870cfb53c4b140fe0bb3fad9eef651d
* | | | Merge branch 'stable-6.8'Matthias Sohn2023-12-042-60/+60
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-6.8: Prepare 6.8.1-SNAPSHOT builds JGit v6.8.0.202311291450-r Rename method parameter to fix warning about hidden field Fix warnings about empty control flow statements BitmapIndexImpl: externalize error message Suppress not-externalized string warnings Silence API error for new method BitmapIndex#addBitmapLookupListener Update Orbit to orbit-aggregation/2023-12 Prepare 6.8.0-SNAPSHOT builds JGit v6.8.0.202311212206-rc1 Change-Id: Ie88662f6458bb80147c7c164424eebd8b8240fc7
| * | | Prepare 6.8.1-SNAPSHOT buildsMatthias Sohn2023-11-292-60/+60
| | | | | | | | | | | | | | | | Change-Id: I56458c5345dcd9544868c948e90c9827d25c6850
| * | | JGit v6.8.0.202311291450-rv6.8.0.202311291450-rMatthias Sohn2023-11-292-2/+2
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Change-Id: Iecfe3f628cfdc437ee0d63fe52653ef952c8c494
* | | | BitmapWalkerTest: New test for the walkerIvan Frade2023-11-301-0/+161
| | | | | | | | | | | | | | | | Change-Id: I414f5bdd86e5623d7669fa187df19e06acd02cef
* | | | FooterLine: First line cannot be a footerIvan Frade2023-11-291-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first line of the commit message cannot be a footer line. This restriction was dropped in commit [1] while adding multiline footers. This affects at least the git-numberer gerrit plugin, that even have a test for it [2]. Reintroduce the restriction that the first line of the commit message cannot be a footer and bring the test from git-numberer to jgit. [1] https://review.gerrithub.io/c/eclipse-jgit/jgit/+/1172664 [2] https://chromium.googlesource.com/infra/gerrit-plugins/git-numberer/+/refs/heads/main/src/test/java/com/googlesource/chromium/plugins/gitnumberer/GetFooterLinesTest.java Change-Id: Id3fa6b8614664dbc3fdccffe1006b0b9752a8de6
* | | | Reapply "Improve footer parsing to allow multiline footers."Ivan Frade2023-11-291-0/+51
| | | | | | | | | | | | | | | | This reverts commit e99fb6edc4b4eba43e27f9945df043e72ab297dd.
* | | | Revert "Improve footer parsing to allow multiline footers."Ivan Frade2023-11-291-51/+0
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 340cc787a0d14a0698d757a919ccd77e0a129fb0. This breaks a test in the git_numberer gerrit plugin used by chromium [1]. The test checks that first line is never a footer, which sounds right. That test should be included in FooterLineTest. [1] https://chromium.googlesource.com/infra/gerrit-plugins/git-numberer/+/refs/heads/main/src/test/java/com/googlesource/chromium/plugins/gitnumberer/GetFooterLinesTest.java
* | | Improve footer parsing to allow multiline footers.Kamil Musin2023-11-241-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the https://git-scm.com/docs/git-interpret-trailers the CGit supports multiline trailers. Subsequent lines of such multiline trailers have to start with a whitespace. We also rewrite the original parsing code to make it easier to work with. The old code had pointers moving both backwards and forwards at the same time. In the rewritten code we first find the start of the last paragraph and then do all the parsing. Since all the getters of the FooterLine return String, I've considered rewriting the parsing code to operate on strings. However the original code seems to be written with the idea, that the data is only lazily copied in getters and no extra allocations should be performed during original parsing (ex. during RevWalk). The changed code keeps to this idea. Bug: Google b/312440626 Change-Id: Ie1e3b17a4a5ab767b771c95f00c283ea6c300220
* | | BitmapIndex: Add interface to track bitmaps found (or not)Ivan Frade2023-11-211-0/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to know what objects had bitmaps in the walk of the request. We can check their position in the history and evaluate our bitmap selection algorithm. Introduce a listener interface to the BitmapIndex to report which getBitmap() calls returned a bitmap (or not) and a method to the bitmap index to set the listener. Change-Id: Iac8fcc1539ddd2dd450e8a1cf5a5b1089679c378
* | | Fix branch ref exist checkflorian.signoret2023-11-181-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | When a tag with the same name as the branch exists, the branch creation process should work too. We should detect that the branch already exists, and allow to force create it when the force option is used. Bug: 582538 Change-Id: I3b350d03be8edcde10e97b2318343240ca896cb0
* | | Adjust javadoc to pass errorprone checksIvan Frade2023-11-174-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bazel build //org.eclipse.jgit.test:all doesn't build due to errorprone errors. This leds to disabling the checks and find the errors later in the jenkins builder. Fix javadoc errors reported by errorprone. This doesn't fix completely the build but it is a step towards it. Change-Id: Ic4ec93a2d71d4628bf3a05277c60157881156393
* | | PatchApplier: wrap output's TemporaryBuffer with a CountingOutputStreamNitzan Gur-Furman2023-11-164-0/+2000015
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The documentation for TemporaryBuffer::length says: "The length is only accurate after {@link #close()} has been invoked". However, we need to have the stream open while accessing the length. This prevents patches on large files to be applied correctly, as the result get trimmed. Bug: Google b/309500446 Change-Id: Ic1540f6d0044088f3b46f1fad5f6a28ec254b711
* | | Optimize RefDirectory.getRefsByPrefix(String...)Dariusz Luksza2023-11-122-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently for file-based repositories JGit will go over all refs in the repository forach `ref-prefix` listed in the `ls-refs` command in git protocol v2 request. Native git, uses a different approach, where all refs are read once and then for each ref, all `ref-prefix` filter values are checked in one pass. This change implements this approach in JGit only in the `RefDirectory` backend. And makes `ref-prefix` filtering ~40% faster for repositories with packed refs. Different implementations were tested on a synthetic file repository with 10k refs in `refs/heads/` and `290k` in `refs/changes`. Before testing `git pack-refs` command was executed. All results are in seconds. Current Impl: 39.340 37.093 35.996 Nested for loops: 25.077 24.742 24.748 Nested streams: 24.827 24.890 27.525 Parallel stream + stream: 23.357 23.318 23.174 Nested parallel streams: 23.490 23.318 23.317 Stream + for loop: 23.147 23.210 23.126 Parallel stream + for loop: 23.317 23.423 22.847 The elapsed time was measured around `getRefByPrefix` call in `Uploadapack.getFilteredRefs(Collection<String>)` (around lines 952 and 954). For testing a modified version of `UploadPackTest.testV2LsRefsRefPrefix()` was used. The modifications here included: * shadowing protected `repo` variable with `FileRepository` pointing to the synthetic repo with 300k refs described above, * mimicking the git client clone request by adding `ref-prefix HEAD`, `ref-prefix refs/heads/` and `ref-prefix refs/tags/` Based on the above results, the implementation with parallel stream and stream was selected. Bug: 578550 Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com> Change-Id: I6416846c074b611ff6ec9d351dbafcfbcaf68e66
* | | Use try-with-resource to ensure UploadPack is closedMatthias Sohn2023-11-091-5/+6
| | | | | | | | | | | | Change-Id: I0d10aeac959a49b3bf2e83b0c104699d1d21f5e9
* | | Fix hiding field warningMatthias Sohn2023-11-091-4/+4
| | | | | | | | | | | | Change-Id: I9aced1b711901918667555a4cfff76992024e59c
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-11 13:35:56 +0000