aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test/tst/org/eclipse/jgit/revwalk
Commit message (Collapse)AuthorAgeFilesLines
* RevCommitParseTest: : use java.time instead of java.util.Date APIMatthias Sohn2024-12-291-10/+15
| | | | Change-Id: I6cf6ed64b4029001cb5908338b60385804eb9997
* CommitTimeRevFilter: Move to java.time APIIvan Frade2024-12-172-2/+128
| | | | | | | | | Deprecate the methods using Date and offer the equivalent as Instant. Keep an int with seconds as internal representation, as it seems more efficient to compare than Instant.before/after. Change-Id: Ie751ab5661c7dafaab58a16c219143b78092f84a
* TestRepository: Deprecate #getDate and use #getInstant insteadIvan Frade2024-12-131-1/+1
| | | | | | | | | | | Errorprone recomments to use the more modern java.time API instead of the java.util.Date family of classes. This removes all uses of TestRepository#getDate and replace them with getInstant. The method is marked as deprecated and doesn't have any other usages. Change-Id: I84ea63abf781d0d3c7c2724891fd2ef7afc2db1d
* RevertCommand: use only first line in revert commit messageThomas Wolf2024-12-111-1/+10
| | | | | | | | | | | | | | | C git uses only the first line of the title paragraph of the reverted commit to build the title of the revert commit. Align the JGit behavior with that. Since git 2.43.0, a revert of a revert uses a title "Reapply "xxx"" instead of "Revert "Revert "xxx""".[1] This is _not_ implemented in this change. [1] https://github.com/git/git/commit/883cb1b8f86d Bug: jgit-117 Change-Id: I030092c6b9447bb738e6d761af5ce50df58cc6d3
* [errorprone] Fix pattern LongLiteralLowerCaseSuffixMatthias Sohn2024-04-291-2/+2
| | | | | | See https://errorprone.info/bugpattern/LongLiteralLowerCaseSuffix Change-Id: I139eadef5d66dfed2952ba9e1c91b3fe83259e97
* Add more tests on rewriting parents in a RevWalkMax Haslbeck2024-03-261-9/+123
| | | | | | | | | | | Change I4e4ff67fb279edbcc3461496b132cea774fb742f introduced new behaviour that also rewrote parents in a RevWalk if no TreeFilter was set. This led to unexpected behaviour when users were fetching from chromium.googlesource.com. I added a few more tests to better describe the behaviour of RevWalk in regards to rewriting parents. Change-Id: I1a5e5f8a1de9d8dd0e3664918ac010644b3ef87b Signed-off-by: Max Haslbeck <haslbeck@google.com>
* TreeRevFilter: correct changedPathFilter usage for multi-paths inclusionXing Huang2024-03-181-0/+30
| | | | | | | | | | | | | | | | The expected behavior of TreeRevFilter when filtering multiple file paths is to include commits that changed at least one of the given paths; only skipping them if they did not change any of the given paths. The current changedPathFilter utilization logic is skipping a commit if there exists at least one given path that the commit did not change, disregarding the rest of the given paths. Enforcing all given paths to be checked by the changedPathFilter, only skipping a commit if changedPathFilter return negative on all given paths. Signed-off-by: Xing Huang <xingkhuang@google.com> Change-Id: Ib7a9e496b37ec737722fbf33c5d0f05d5d910a8d
* 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
* CherryPick: add ability to customise cherry-picked commit messageDmitrii Naumenko2024-01-281-0/+8
| | | | | | | | | | | | | | | | | 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>
* | | | 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
* | | | 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
* | | | 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
* | Move footer-line parsing methods from RevCommit to FooterLineNitzan Gur-Furman2023-08-011-99/+92
| | | | | | | | | | | | | | | | | | | | This allows extracting footers from a messages not associated with a commit. The public API of RevCommit is kept intact. Change-Id: I5809c23df7b7d49641a4be3a26d6f987d3d57c9b Bug: Google b/287891316
* | Identify a commit that generates a diffEntry on a rename Event.Ronald Bhuleskar2023-07-241-0/+24
| | | | | | | | | | | | | | | | When using FollowFilter's rename callback, a callback is generated with the diff. The caller that is interested in the renames knows what the diff's are but have no idea what commit generated that diff. This will allow FollowFilter's rename callback to track diffEntry for a given commit. Change-Id: If1e63ccd19fdcb9c58c59137110fe24e0ce023d2
* | CommitGraphWriter: add option for writing/using bloom filtersRonald Bhuleskar2023-07-181-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, bloom filters are written and used without any way to turn them off. Add a per-repo config variable to control whether bloom filters are written. As for reading, add a JGit option to control this. (A JGit option is used instead of a per-repo config variable as there is usually no reason not to use the bloom filters if they are present, but a global control to disable them is useful if there turns out to be an issue with the implementation of bloom filters.) The config that controls reading is the same as C Git, but the config for writing is not: C Git has no config to control writing, but whether bloom filters are written depends on whether bloom filters are already present and what arguments are passed to "git commit-graph write". See the manpage of "git commit-graph" for more information. Change-Id: I1b7b25340387673506252b9260b22bfe147bde58
* | RevWalk: use changed path filtersJonathan Tan2023-07-181-0/+67
|/ | | | | | | | | | | | | Teach RevWalk, TreeRevFilter, PathFilter, and FollowFilter to use changed path filters, whenever available, to speed revision walks by skipping commits that fail the changed path filter. This work is based on earlier work by Kyle Zhao (I441be984b609669cff77617ecfc838b080ce0816). Change-Id: I7396f70241e571c63aabe337f6de1b8b9800f7ed Signed-off-by: kylezhao <kylezhao@tencent.com> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
* RewriteGeneratorTest: Introduce test cases for the RewriteGeneratorSimon Sohrt2023-05-091-0/+63
| | | | | | Bug: 577948 Signed-off-by: Simon Sohrt <sohrt@his.de> Change-Id: I5af1a43d49379e2417611eaacdd5f06be8147bc4
* RevWalk: use generation number to optimize getMergedInto()kylezhao2023-04-121-0/+93
| | | | | | | | | | | | | | | | | | | | A commit A can reach a commit B only if the generation number of A is strictly larger than the generation number of B. This condition allows significantly short-circuiting commit-graph walks. On a copy of the Linux repository where HEAD is contained in v6.3-rc4 but no earlier tag, the command 'git tag --contains HEAD' of ListTagCommand#call() had the following peformance improvement: (excluded the startup time of the repo) Before: 2649ms (core.commitgraph=true) 11909ms (core.commitgraph=false) After: 91ms (core.commitgraph=true) 11934ms (core.commitgraph=false) Bug: 574368 Change-Id: Ia2efaa4e9ae598266f72e70eb7e3b27655cbf85b Signed-off-by: kylezhao <kylezhao@tencent.com>
* Ensure parsed RevCommitCG has derived data from commit-graphkylezhao2023-04-061-0/+36
| | | | | | | | | | If a RevCommitCG was newly created and called #parseCanonical(RevWalk, byte[]) method immediately, its flag was marked as PARSED, but no derived data was obtained from the commit-graph. This is different from what we expected. Change-Id: I5d417efa3c42d211f19e6acf255f761e84d84450 Signed-off-by: kylezhao <kylezhao@tencent.com>
* Avoid error-prone warningHan-Wen Nienhuys2023-02-011-1/+1
| | | | | | | GC.gc() returns a Future, which should not be discarded. See also https://errorprone.info/bugpattern/FutureReturnValueIgnored Change-Id: I343cc3cfe74a564ad7f8d53f0fe9d96a23aaed00
* RevWalk: integrate commit-graph with commit parsingkylezhao2023-01-101-0/+319
| | | | | | | | | | | | | | | | | | | | | | | | | RevWalk#createCommit() will inspect the commit-graph file to find the specified object's graph position and then return a new RevCommitCG instance. RevCommitGC is a RevCommit with an additional "pointer" (the position) to the commit-graph, so it can load the headers and metadata from there instead of the pack. This saves IO access in walks where the body is not needed (i.e. #isRetainBody is false and #parseBody is not invoked). RevWalk uses automatically the commit-graph if available, no action needed from callers. The commit-graph is fetched on first access from the reader (that internally can keep it loaded and reuse it between walks). The startup cost of reading the entire commit graph is small. After testing, reading a commit-graph with 1 million commits takes less than 50ms. If we use RepositoryCache, it will not be initialized util the commit-graph is rewritten. Bug: 574368 Change-Id: I90d0f64af24f3acc3eae6da984eae302d338f5ee Signed-off-by: kylezhao <kylezhao@tencent.com>
* Revert "Adds FilteredRevCommit that can overwrites its parents in theMatthias Sohn2022-09-065-381/+45
| | | | | | | | | | | | DAG." This reverts commit 6297491e8adb85e43d60ffe75fb71f335e733449. This is done as a quick fix for the failure of egit tests caused by the introduction of FilteredRevCommit. Bug: 580690 Change-Id: Ia6b651dd11b0a4b02d5e52247eb4bf13adf94e27
* Adds FilteredRevCommit that can overwrites its parents in the DAG.Ronald Bhuleskar2022-08-165-45/+381
| | | | Change-Id: I1ea63a3b56074099688fc45d6a22943a8ae3c2ae
* Revert "Adds FilteredRevCommit that can overwrites its parents in the DAG."Ronald Bhuleskar2022-08-034-273/+18
| | | | | | | | | | This reverts commit ceb51a5e0e9db166e572ea7cd362795b4662b0cd. Reason for revert: The change in https://git.eclipse.org/r/c/jgit/jgit/+/194354 broke the egit test [1]. Calling c.getShortMessage() causes an NPE. [1] https://ci.eclipse.org/egit/job/egit.gerrit/2711/ Change-Id: I411565b6eaa0bbb562cc1c8a355942ff09fd29bc
* Adds FilteredRevCommit that can overwrites its parents in the DAG.Ronald Bhuleskar2022-08-024-18/+273
| | | | Change-Id: I2df9843dde0f589f5fea6cedaaff52e313eea6de
* Add the ability to override parents on RevCommit.Ronald Bhuleskar2022-08-023-50/+245
| | | | | | | | | | | | | | | | | | | This makes RevCommit extensible to allow having different structure of child-parent relationship. This change is a pre-requsite for having a FilteredRevCommit that overrides parents from the RevCommit. That then provides a cheaper way to walk over a subset of RevCommits instead of an expensive way that applies filters while walking over selected commits. Useful with Blame which works on a single file and that can be made performant, if we know all the commits needed by the Blame algorithm. So Blame algorithm can avoid walking over finding what commits to blame on. This change makes parents field on RevCommit private and exposes it thrrough overrideable methods such as getParents, getParent at index, getParentCount and setParents. All other files other than RevCommit are updating the usages of accessing RevCommits parents. Change-Id: I2d13b001c599cc4ebc92d1ab6e07b07acb3b7fe5
* TreeRevFilter: fix wrong stop when the given path disappearskylezhao2021-12-171-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | When chgs[i] == adds[i], it indicated that a commit added some files that pList[i] did not have, but didn't mean pList[i] is "empty tree root". Follow the example below: . . └── src └── src └── d1 ==> └── d1 └─ file1 ├─ file1 └── file2 c.parents[i] c The variable chg[i] equals to variable add[i], but commit c.parents[i] is not "empty tree root". We should add an additional check for no paths matching the filter. Bug: 577227 Change-Id: I834e9ddd0de86b108b280a1139519ea962913b38 Signed-off-by: kylezhao <kylezhao@tencent.com>
* Fix RevWalk.getMergedInto() ignores annotated tagskylezhao2021-10-081-1/+20
| | | | | | | If an annotated tag refers to a commit, we should not ignore it. Change-Id: I77504f93636e9e984540e7d8535ef301adce6a80 Signed-off-by: kylezhao <kylezhao@tencent.com>
* Optimize RevWalk.getMergedInto()kylezhao2021-10-081-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Transitive Relation Definition: On the DAG of commit history, if A can reach B, C can reach A, then C can reach B. Example: As is shown in the graph below: 1 - 2 - 3 - 4 (side) \ 5 - 6^ (master) - 7 (topic) Find out which branches is 2 merged into: After we calculated that master contains 2, we can mark 6 as TEMP_MARK to avoid unwanted walks. When we want to figure out if 2 is merge into the topic, the traversal path would be [7, 6] instead of [7, 6, 5, 3, 2]. Test: This change can significantly improve performance for tags. On a copy of the Linux repository, the command 'git tag --contains <commit>' had the following performance improvement: commit | Before | After | Rel % 47a44d27ca | 29251ms | 6687ms | -77% 90327e7dff | 21388ms | 6256ms | -70% f85fac0efa | 11150ms | 7338ms | -34% The current version ignores tags, even though the tag is a type of the ref. Follow-up commits I'll fix it. Change-Id: Ie6295ca4d16070499912af462239e679a97cce47 Signed-off-by: kylezhao <kylezhao@tencent.com> Reviewed-by: Christian Halstrick <christian.halstrick@sap.com> Reviewed-by: Martin Fick <mfick@codeaurora.org>
* RevWalk: getMergedInto's result is wrong on the second callkylezhao2021-08-131-0/+22
| | | | | | | | Make sure the future user can reset all UNINTERESTING commmits after this operation. Signed-off-by: kylezhao <kylezhao@tencent.com> Change-Id: I7549b9ff67bd31acd5dfc92331cb9a30b47b8278
* Introduce getMergedInto(RevCommit commit, Collection<Ref> refs)Adithya Chakilam2021-03-141-0/+81
| | | | | | | | | | | | | | | In cases where we need to determine if a given commit is merged into many refs, using isMergedInto(base, tip) for each ref would cause multiple unwanted walks. getMergedInto() marks the unreachable commits as uninteresting which would then avoid walking that same path again. Using the same api, also introduce isMergedIntoAny() and isMergedIntoAll() Change-Id: I65de9873dce67af9c415d1d236bf52d31b67e8fe Signed-off-by: Adithya Chakilam <quic_achakila@quicinc.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix DateRevQueue tie breaks with more than 2 elementsAdithya Chakilam2021-02-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DateRevQueue is expected to give out the commits that have higher commit time. But in case of tie(same commit time), it should give the commit that is inserted first. This is inferred from the testInsertTie test case written for DateRevQueue. Also that test case, right now uses just two commits which caused it not to fail with the current implementation, so added another commit to make the test more robust. By fixing the DateRevQueue, we would also match the behaviour of LogCommand.addRange(c1,c2) with git log c1..c2. A test case for the same is added to show that current behaviour is not the expected one. By fixing addRange(), the order in which commits are applied during a rebase is altered. Rebase logic should have never depended upon LogCommand.addRange() since the intended order of addRange() is not the order a rebase should use. So, modify the RebaseCommand to use RevWalk directly with TopoNonIntermixSortGenerator. Add a new LogCommandTest.addRangeWithMerge() test case which creates commits in the following order: A - B - C - M \ / -D- Using git 2.30.0, git log B..M outputs: M C D LogCommand.addRange(B, M) without this fix outputs: M D C LogCommand.addRange(B, M) with this fix outputs: M C D Change-Id: I30cc3ba6c97f0960f64e9e021df96ff276f63db7 Signed-off-by: Adithya Chakilam <achakila@codeaurora.org>
* Move reachability checker generation into the ObjectReader objectTerry Parker2021-01-286-394/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reachability checkers are retrieved from RevWalk and ObjectWalk objects: * RevWalk.createReachabilityChecker() * ObjectWalk.createObjectReachabilityChecker() Since RevWalks and ObjectWalks are themselves directly instantiated in hundreds of places (e.g. UploadPack...) overriding them in a consistent way requires overloading 100s of methods, which isn't feasible. Moving reachability checker generation to a more central place solves that problem. The ObjectReader object seems a good place from which to get reachability checkers, because reachability checkers return information about relationships between objects. ObjectDatabases delegate many operations to ObjectReaders, and reachability bitmaps are attached to ObjectReaders. The Bitmapped and Pedestrian reachability checker objects were package private in the org.eclipse.jgit.revwalk package. This change makes them public and moves them to the org.eclipse.jgit.internal.revwalk package. Corresponding tests are also moved. Motivation: 1) Reachability checking algorithms need to scale. One of the internal Android repositories has ~2.4 million refs/changes/* references, causing bad long tail performance in reachability checks. 2) Reachability check performance is impacted by repository topography: number of refs, number of objects, amounts of related vs. unrelated history. 3) Reachability check performance is also affected by per-branch access (Gerrit branch permissions) since different users can see different branches. 4) Reachability check performance isn't affected by any state in a RevWalk or ObjectWalk. I don't yet know if a single algorithm will work for all cases in #2 and #3. We may need to evolve the ReachabilityChecker interfaces over time to solve the Gerrit branch permissions case, or use Gerrit-specific identity information to solve that in an efficient way. This change takes the existing public API and moves it to the ObjectReader/whole repository level, which is where we can do consistent customizations for #2 and #3. We intend to upstream the best of whatever works, but anticipate the need for multiple rounds of experimentation. Change-Id: I9185feff43551fb387957c436112d5250486833d Signed-off-by: Terry Parker <tparker@google.com>
* Tag message must not include the signatureThomas Wolf2021-01-101-6/+6
| | | | | | | | | | | | Signatures on tags are just tacked onto the end of the message. Getting the message must not return the signature. Compare [1] and [2] in C git, which both drop a signature at the end of an object body. [1] https://github.com/git/git/blob/21bf933/builtin/tag.c#L173 [2] https://github.com/git/git/blob/21bf933/ref-filter.c#L1276 Change-Id: Ic8a1062b8bc77f2d7c138c3fe8a7fd13b1253f38 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Enable GpgSigner to also sign tagsThomas Wolf2020-12-071-6/+113
| | | | | | | | | | | | | | Factor out a common ObjectBuilder as super class of CommitBuilder and TagBuilder, and make the GpgSigner work on ObjectBuilder. In order not to break API, add the new method for signing an ObjectBuilder in a new interface GpgObjectSigner. The signature for a tag is just tacked onto the end of the tag message. The message of a signed tag must end in LF. Bug: 386908 Change-Id: I5e021e3c927f4051825cd7355b129113b949455e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* revwalk: Introduce bitmap-based object reachability checkerIvan Frade2020-04-281-0/+31
| | | | | Change-Id: I0b1a2bd21f98894862aab339f8c2e4a417897b89 Signed-off-by: Ivan Frade <ifrade@google.com>
* revwalk: Extract ObjectReachabilityChecker interfaceIvan Frade2020-04-282-135/+146
| | | | | | | | | | Extract ObjectReachabilityChecker interface from the walk-based implementation, to add a bitmapped based implementation later. Refactor the test case to use it for both implementations. Change-Id: Iaac7c6b037723811956ac22625f27d3b4d742139 Signed-off-by: Ivan Frade <ifrade@google.com>
* UploadPack: Extract walk-based reachability checkIvan Frade2020-04-281-0/+157
| | | | | | | | | | | | | | Preparing the code to optimize the bitmap-based object reachability checker. We are mirroring first the commit reachability checker structure (interface + 2 implementations). Move the walk-base reachability checker to its own class. This class is public at the moment. Later ObjectWalk will return an interface and this implementation will be package-private. Change-Id: Ifac70094e1af137291c3607d95e689992f814b26 Signed-off-by: Ivan Frade <ifrade@google.com>
* RevWalk: fix bad topo flags error messageAlex Spradlin2020-03-121-1/+1
| | | | | | | | | | | | | | The error message for an Exception thrown by StartGenerator when given both the TOPO flag and the TOPO_KEEP_BRANCH_TOGETHER flag mentions a non-existent flag, TOPO_NON_INTERMIX. The error message was introduced in commit e498d43. Replace TOPO_NON_INTERMIX with TOPO_KEEP_BRANCH_TOGETHER in the error message of an Exception thrown by the StartGenerator when the TOPO flag is provided together with the TOPO_KEEP_BRANCH_TOGETHER flag. Signed-off-by: Alex Spradlin <alexaspradlin@google.com> Change-Id: Id24640dc08e96a196508fe38ce144aa7e035082f
* RevWalk: new topo sort to not mix lines of historyAlex Spradlin2020-03-112-0/+222
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The topological sort algorithm in TopoSortGenerator for RevWalk may mix multiple lines of history, producing results that differ from C git's git-log whose man page states: "Show no parents before all of its children are shown, and avoid showing commits on multiple lines of history intermixed." Lines of history are mixed because TopoSortGenerator merely delays producing a commit until all of its children have been produced; it does not immediately produce a commit after its last child has been produced. Therefore, add a new RevSort option called TOPO_KEEP_BRANCH_TOGETHER with a new topo sort algorithm in TopoNonIntermixGenerator. In the Generator, when the last child of a commit has been produced, unpop that commit so that it will be returned upon the subsequent call to next(). To avoid producing duplicates, mark commits that have not yet been produced as TOPO_QUEUED so that when a commit is popped, it is produced if and only if TOPO_QUEUED is set. To support nesting with other generators that may produce the same commit multiple times like DepthGenerator (for example, StartGenerator does this), do not increment parent inDegree for the same child commit more than once. Commit b5e764abd21bd4593287361a625ecc49bc0efd77 modified the existing TopoSortGenerator to avoid mixing lines of history, but it was reverted in e40c38ab08837473375c571c2f07ab680fc1985d because the new behavior caused problems for EGit users. This motivated adding a new Generator for the new behavior. Signed-off-by: Alex Spradlin <alexaspradlin@google.com> Change-Id: Icbb24eac98c00e45c175b01e1c8122554f617933
* Merge "ObjectWalk: Add null check before skip tree."Jonathan Nieder2020-03-021-0/+8
|\
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-14 22:18:31 +0000