aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test/tst-rsrc
Commit message (Collapse)AuthorAgeFilesLines
* Support built-in diff drivers for hunk header function namesKaushik Lingarkar2024-11-205-0/+158
| | | | | | | | | | | | | | | | | | | | The regexes defined for each built-in driver will be used to determine the function name for a hunk header. Each driver can specify a list of regexes to negate and match. They can also define pattern compilation flags if needed. These drivers only apply to text files with unified patch type. Following built-in drivers have been added: - cpp - dts - java - python - rust Support for more languages can be added as needed to match the cgit implementation. Change-Id: Ice5430bfed7e4aaf9f00e52e44402479984953c5
* PatchApplier: Add test for conflict markers on a deleted filePatrick Hiesel2024-05-271-0/+10
| | | | | | | | For deleted files, we want to keep erroring out even if conflicts are allowed for the apply patch logic. The resulting file would otherwise only consist of the patch. Change-Id: I18defa627ad2223a3a917d2b0ee4189396732533
* Allow applying a patch with conflictsPatrick Hiesel2024-05-146-0/+66
| | | | | | | | | | | | | | In some settings, we want to let users apply a patch that does not cleanly apply and add conflict markers. In Gerrit, this is useful when cherry picking (via Git patches) from one host to another. This commit takes a simple approach: If a hunk doesn't apply, go to the pre-image line, treat all lines in pre-image length as left side of the conflict and all context and newly added lines as right side of the conflict. Change-Id: I01411d7a32b3f3207097b26231909aae6b835650
* PatchApplier: wrap output's TemporaryBuffer with a CountingOutputStreamNitzan Gur-Furman2023-11-163-0/+2000007
| | | | | | | | | | | | 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
* Merge branch 'stable-6.6' into stable-6.7Matthias Sohn2023-09-034-0/+28
|\ | | | | | | | | | | | | | | | | * stable-6.6: Prepare 6.6.2-SNAPSHOT builds JGit v6.6.1.202309021850-r Checkout: better directory handling Change-Id: Ice82d68b2d343a5fac214807cdb369e486481aab
| * Checkout: better directory handlingThomas Wolf2023-09-034-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When checking out a file into the working tree ensure that all parent directories of the file below the working tree root are actually directories and do exist before we try to create the file. When multiple files are to be checked out (or even a whole tree), this may check the same directories over and over again. Asking the file system every time for file attributes is a potentially expensive operation. As a remedy, introduce an in-memory cache of directory states for a particular check-out operation. Apply the same fix also in the ResolveMerger, which may also check out files, and also in the PatchApplier. In PatchApplier, also validate paths. Change-Id: Ie12864c54c9f901a2ccee7caddec73027f353111 Signed-off-by: Thomas Wolf <twolf@apache.org> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | PackReverseIndex: open file if present otherwise computeAnna Papitto2023-07-182-0/+0
|/ | | | | | | | | | | | | | | | The existing #read and #computeFromIndex static builder methods require the caller to choose whether to supply an input stream of a reverse index file or a forward index to compute the reverse index from, which is slower. Allow a caller to provide a file path where the pack's reverse index might be and the pack's forward index index and simply get some reverse index instance back. Prefer opening and parsing the file if it is present, to save computation time. Otherwise, fall back onto computing the reverse index from the pack's forward index. Change-Id: I09bdd4b813ad62c86add586417b2ab86e9331aec Signed-off-by: Anna Papitto <annapapitto@google.com>
* PatchApplierTest: Remove test data with Apache licenseIvan Frade2023-03-283-739/+0
| | | | | | | | | | | | Some test data introduced in [1] includes code with Apache license. This triggers warnings in license analyzers. Remove the licensed files and the test case as a quick relief. We should restore the test with appropiate data in a follow-up change. [1] https://git.eclipse.org/r/c/jgit/jgit/+/197724 Change-Id: I42670dc7d994f77d2c7f2c2156bcf1e112374022
* Fix PatchApplier error handling.Nitzan Gur-Furman2023-03-283-0/+10
| | | | | | | | | | | | | | | | 1. For general errors, throw IOException instead of wrapping them with PatchApplyException. The wrapping was moved (back) to ApplyCommand. 2. For file specific errors, log the errors as part of PatchApplier::Result. 3. Change applyPatch() to receive the parsed Patch object, so the caller can decide how to handle parsing errors. Background: this utility class was extracted from ApplyCommand on V6.4.0. During the extraction, we left the exception wrapping by PatchApplyException intact. This attitude made it harder for the callers to distinguish between the actual error causes. Change-Id: Ib0f2b5e97a13df2339d8b65f2fea1c819c161ac3
* PatchApplier fix - init cache with provided treeNitzan Gur-Furman2023-02-023-0/+36
| | | | | | | | | This change only affects inCore repositories. Before this change, any file that wasn't part of the patch wasn't read, and therefore wasn't part of the output tree. Change-Id: I246ef957088f17aaf367143f7a0b3af0f8264ffb Bug: Google b/267270348
* PatchApplier: fix handling of last newline in text patchThomas Wolf2022-12-2636-0/+1073
| | | | | | | | | | | | | | | | | | | | | | If the last line came from the patch, use the patch to determine whether or not there should be a trailing newline. Otherwise use the old text. Add test cases for - no newline at end, last line not in patch hunk - no newline at end, last line in patch hunk - patch removing the last newline - patch adding a newline at the end of file not having one all for core.autocrlf false, true, and input. Add a test case where the "no newline" indicator line is not the last line of the last hunk. This can happen if the patch ends with removals at the file end. Bug: 581234 Change-Id: I09d079b51479b89400ad300d0662c1dcb50deab6 Also-by: Yuriy Mitrofanov <a2terminator@mail.ru> Signed-off-by: Thomas Wolf <twolf@apache.org>
* CommitGraph: implement commit-graph readkylezhao2022-12-161-0/+0
| | | | | | | | | | | | | | | | | | | | Git introduced a new file storing the topology and some metadata of the commits in the repo (commitGraph). With this data, git can browse commit history without parsing the pack, speeding up e.g. reachability checks. This change teaches JGit to read commit-graph-format file, following the upstream format([1]). JGit can read a commit-graph file from a buffered stream, which means that we can provide this feature for both FileRepository and DfsRepository. [1] https://git-scm.com/docs/commit-graph-format/2.21.0 Bug: 574368 Change-Id: Ib5c0d6678cb242870a0f5841bd413ad3885e95f6 Signed-off-by: kylezhao <kylezhao@tencent.com>
* AmazonS3: Add support for AWS API signature version 4eric.steele2022-06-131-0/+9
| | | | | | | | | | | | Updating the AmazonS3 class to support AWS Signature version 4 because version 2 is no longer supported in all AWS regions. The version can be selected with the new 'aws.api.signature.version' property (defaults to 2 for backwards compatibility). When set to '4', the user must also specify the AWS region via the 'region' property. The 'region' property must match the region that the 'domain' property resolves to. Bug: 579907 Change-Id: If289dbc6d0f57323cfeaac2624c4eb5028f78d13
* Use slf4j-simple instead of log4j for loggingMatthias Sohn2021-12-312-20/+6
| | | | | | | | | | | | | | | | | | | | | JGit uses slf4j-api as logging API. The libraries - org.eclipse.jgit.http.test - org.eclipse.jgit.pgm - org.eclipse.jgit.ssh.apache.test - org.eclipse.jgit.test used the outdated log4j 1.2.15 which is EOL since years. Since both jgit command line and also the tests don't need sophisticated logging features replace log4j with the much simpler slf4j-simple log implementation. The org.slf4j.binding.simple 1.7.30 archive has only 25kB instead of 429kB for log4j 1.2.15 Applications using jgit are free to choose any other log implementation supporting slf4j API. Change-Id: I89e85cd3c76e954c3434622510975ce65dc227d4
* ApplyCommand: fix "no newline at end" detectionThomas Wolf2021-05-263-0/+18
| | | | | | | | | | | Check the last line of the last hunk of a file, not the last line of the whole patch. Note that C git only checks that this line starts with "\ " and is at least 12 characters long because of possible different texts when non- English messages are used. Change-Id: I0db81699eb3e99ed7b536a3e2b8dc97df1f58a89 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* ApplyCommand: handle completely empty context lines in text patchesThomas Wolf2021-05-263-0/+18
| | | | | | | | | | C git treats completely empty lines as empty context lines (which traditionally have a single blank). Apparently newer GNU diff may produce such lines; see [1]. ("Newer" meaning "since 2006"...) [1] https://github.com/git/git/commit/b507b465f7831 Change-Id: I80c1f030edb17a46289b1dabf11a2648d2660d38 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* ApplyCommand: use byte arrays for text patches, not stringsThomas Wolf2021-05-263-0/+9
| | | | | | | | | | | | | | | | | | | | | Instead of converting the patch bytes to strings apply the patch on byte level, like C git does. Converting the input lines and the hunk lines from bytes to strings and then applying the patch based on strings may give surprising results if a patch converts a text file from one encoding to another. Moreover, in the end we don't know which encoding to use to write the result. Previous code just wrote the result as UTF-8, which forcibly changed the encoding if the original input had some other encoding (even if the patch had the same non-UTF-8 encoding). It was also wrong if the input was UTF-8, and the patch should have changed the encoding to something else. So use ByteBuffers instead of Strings. This has the additional advantage that all these ByteBuffers can share the underlying byte arrays of the input and of the patch, so it also reduces memory consumption. Change-Id: I450975f2ba0e7d0bec8973e3113cc2e7aea187ee Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* ApplyCommand: support binary patchesThomas Wolf2021-05-269-0/+176
| | | | | | | | | | | | | | Implement applying binary patches. Handles both literal and delta patches. Note that C git also runs binary files through the clean and smudge filters. Implement the same safeguards against corrupted patches as in C git: require the full OIDs to be present in the patch file, and apply a binary patch only if both pre- and post-image hashes match. Add tests for applying literal and delta patches. Bug: 371725 Change-Id: I71dc214fe4145d7cc8e4769384fb78c7d0d6c220 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* ApplyCommand: add a stream to apply a delta patchThomas Wolf2021-05-262-0/+2
| | | | | | | | | | | | | Add a new BinaryDeltaInputStream that applies a delta provided by another InputStream to a given base. Because delta application needs random access to the base, the base itself cannot be yet another InputStream. But at least this enables streaming of the result. Add a simple test using delta hunks generated by C git. Bug: 371725 Change-Id: Ibd26fa2f49860737ad5c5387f7f4870d3e85e628 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* ApplyCommand: convert to git internal format before applying patchThomas Wolf2021-05-1814-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Applying a patch on Windows failed if the patch had the (normal) single-LF line endings, but the file on disk had the usual Windows CR-LF line endings. Git (and JGit) compute diffs on the git-internal blob, i.e., after CR-LF transformation and clean filtering. Applying patches to files directly is thus incorrect and may fail if CR-LF settings don't match, or if clean/smudge filtering is involved. Change ApplyCommand to run the file content through the check-in filters before applying the patch, and run the result through the check-out filters. This makes patch application succeed even if the patch has single-LFs, but the file has CR-LF and core.autocrlf is true. Add tests for various combinations of line endings in the file and in the patch, and a test to verify the clean/smudge handling. See also [1]. Running the file though clean/smudge may give strange results with LFS-managed files. JGit's DiffFormatter has some extra code and applies the smudge filter again after having run the file through the check-in filters (CR-LF and clean). So JGit can actually produce a diff on LFS-managed files using the normal diff machinery. (If it doesn't run out of memory, that is. After all, LFS is intended for _large_ files.) How such a diff would be applied with either C git or JGit is entirely unclear; neither has any code for this special case. Compare also [2]. Note that C git just doesn't know about LFS and always diffs after the check-in filter chain, so for LFS files, it'll produce a diff of the LFS pointers. [1] https://github.com/git/git/commit/c24f3abac [2] https://github.com/git-lfs/git-lfs/issues/440 Bug: 571585 Change-Id: I8f71ff26313b5773ff1da612b0938ad2f18751f5 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* HTTP: cookie file stores expiration in secondsThomas Wolf2021-03-034-6/+8
| | | | | | | | | | | | | A cookie file stores the expiration in seconds since the Linux Epoch, not in milliseconds. Correct reading and writing cookie files; with a backwards-compatibility hack to read files that contain a millisecond timestamp. Add a test, and fix tests not to rely on the actual current time so that they will also run successfully after 2030-01-01 noon. Bug: 571574 Change-Id: If3ba68391e574520701cdee119544eedc42a1ff2 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Fix possible NegativeArraySizeException in PackIndexV1Marc Strapetz2020-08-252-0/+0
| | | | | | | | | Due to an integer overflow bug, the current "Index file is too large for jgit" check did not work properly and subsequently a NegativeArraySizeException was raised. Change-Id: I2736efb28987c29e56bc946563b7fa781898a94a Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
* DirCache: support index V4Thomas Wolf2020-08-151-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Index format version 4 was introduced in C git in 2012. It's about time that JGit can deal with it. Version 4 added prefix path compression. Instead of writing the full path for each index entry to disk, only the difference to the previous entry's path is written: a variable-encoded int telling how many bytes to remove from the previous entry's path to get the common prefix, followed by the new suffix. Also, cache entries in a version 4 index are not padded anymore. Internally, version 3 and version 4 index entries are identical; it's only the stored format that changes. Implement this path compression, and make sure we write an index file that we read previously in the same format. (Only changing from version 2 to version 3 if there are extended flags.) Add support for the "feature.manyFiles" and the "index.version" git configs, and honor them when writing a new index file. Add tests, including a compatibility test that verifies that JGit can read a version 4 index generated by C git and write an identical version 4 index. Bug: 565774 Change-Id: Id83241cf009e50f950eb42f8d56b834fb47da1ed Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* ApplyCommand: use context lines to determine hunk locationThomas Wolf2020-06-0412-0/+494
| | | | | | | | | | | | | | If a hunk does not apply at the position stated in the hunk header try to determine its position using the old lines (context and deleted lines). This is still a far cry from a full git apply: it doesn't do binary patches, it doesn't handle git's whitespace options, and it's perhaps not the fastest on big patches. C git hashes the lines and uses these hashes to speed up matching hunks (and to do its whitespace magic). Bug: 562348 Change-Id: Id0796bba059d84e648769d5896f497fde0b787dd Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Attributes: fix handling of text=auto in combination with eolThomas Wolf2020-05-221-0/+0
| | | | | | | | | | | | | | | In Git 2.10.0 the interpretation of gitattributes changed or was fixed such that "* text=auto eol=crlf" would indeed still do auto-detection of text vs. binary content.[1] Previously this was identical to "* text eol=crlf", i.e., treating all files as text. JGit still did the latter, which caused surprises because it changed binary files. [1] https://github.com/git/git/blob/master/Documentation/RelNotes/2.10.0.txt#L248 Bug: 561341 Change-Id: I5b6fb97b5e86fd950a98537b6b8574f768ae30e5 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Apply hunks when renaming or copying from patch filesJack Wickham2020-05-066-0/+42
| | | | | | | | When applying a patch that contains renames or copies using ApplyCommand, also apply all hunks that apply to the renamed or copied file. Change-Id: I9f3fa4370458bd7c14beeb2e2b49e846d70203cb Signed-off-by: Jack Wickham <jwickham@palantir.com>
* Create parent directories when renaming a file in ApplyCommandJack Wickham2020-05-063-0/+12
| | | | | | | | | | | | Before this change, applying a patch will fail if the destination directory doesn't exist; after, the necessary parent directories are created. If renaming the file fails, the directories won't be deleted, so this change isn't atomic. However, ApplyCommand is already not atomic - if one hunk fails to apply, other hunks still get applied - so I don't think that is a blocker. Change-Id: Iea36138b806d4e7012176615bcc673756a82f365 Signed-off-by: Jack Wickham <jwickham@palantir.com>
* Merge branch 'stable-5.4'Matthias Sohn2019-08-202-2/+11
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-5.4: Fix NPE in RebaseTodoFile#parseComments Fix NPE in ObjectIdOwnerMap#get Fix NPE in CommitOnlyTest#getHead FileUtils#lastModifiedInstant should not log error if path doesn't exist Cache user global and system-wide git configurations Avoid setup and saving FileStoreAttributes compete for ~/.gitconfig lock Add missing dependencies for running FS_POSIXTest in Eclipse Fix javadoc for SystemReader#getInstance Upgrade tycho-extras to 1.4.0 Improve retry handling when saving FileStoreAttributes fails Ensure FSTest uses MockSystemReader Make supportsAtomicCreateNewFile return true as default Update orbit to R20190602212107-2019-06 to enable backports from master Handle InvalidPathException in FS_POSIX#createNewFileAtomic Ensure root cause of lock creation failures is logged Implement toString in MockSystemReader and MockConfig LocalDiskRefTreeDatabaseTest shall use MockSystemReader Ensure LocalDiskRepositoryTestCase#setup fully uses MockSystemReader Ensure we use MockSystemReader in tests Override FileBasedConfig's save method in MockConfig Remove FileBasedConfig.load(boolean) introduced in d45219ba Disable debug log for FS in org.eclipse.jgit.test Bazel: enable logging for tests in org.eclipse.jgit.test LockFile: log exception if creation of lock file failed Stop using deprecated Constants.CHARACTER_ENCODING Change-Id: I709de5edb626536529a99220aae7751b127c9bff Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * Merge branch 'stable-5.3' into stable-5.4Matthias Sohn2019-08-202-2/+11
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-5.3: Fix NPE in RebaseTodoFile#parseComments Fix NPE in ObjectIdOwnerMap#get Fix NPE in CommitOnlyTest#getHead FileUtils#lastModifiedInstant should not log error if path doesn't exist Cache user global and system-wide git configurations Avoid setup and saving FileStoreAttributes compete for ~/.gitconfig lock Add missing dependencies for running FS_POSIXTest in Eclipse Fix javadoc for SystemReader#getInstance Improve retry handling when saving FileStoreAttributes fails Ensure FSTest uses MockSystemReader Make supportsAtomicCreateNewFile return true as default Update orbit to R20190602212107-2019-06 to enable backports from master Handle InvalidPathException in FS_POSIX#createNewFileAtomic Ensure root cause of lock creation failures is logged Implement toString in MockSystemReader and MockConfig LocalDiskRefTreeDatabaseTest shall use MockSystemReader Ensure LocalDiskRepositoryTestCase#setup fully uses MockSystemReader Ensure we use MockSystemReader in tests Override FileBasedConfig's save method in MockConfig Remove FileBasedConfig.load(boolean) introduced in d45219ba Disable debug log for FS in org.eclipse.jgit.test Bazel: enable logging for tests in org.eclipse.jgit.test LockFile: log exception if creation of lock file failed Stop using deprecated Constants.CHARACTER_ENCODING Change-Id: I43c2ab8b44c3e87d48e4072907ad169c81e3ffe0 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | * Disable debug log for FS in org.eclipse.jgit.testMatthias Sohn2019-08-101-1/+1
| | | | | | | | | | | | | | | | | | | | | This was enabled unintentionally in 06fc6c7c and spams the test logs. We can enable this when needed. Change-Id: I9f3042c0e285ff236be65fcc02bdcfdb90efc3af Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | * Bazel: enable logging for tests in org.eclipse.jgit.testMatthias Sohn2019-08-102-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | - use slf4j-simple for logging in test runs - for log configuration see https://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html Change-Id: I9f0a532644b31162c867cd0d63f083296eaf6be5 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Fix ApplyCommand which doesn't work if patch adds empty fileAnton Khodos2019-08-192-0/+3
|/ / | | | | | | | | | | Bug: 548219 Change-Id: Ibb32132a38e54508a24489322da58ddfd80a1d9a Signed-off-by: Anton Khodos <khodosanton@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Merge branch 'stable-5.3' into stable-5.4Matthias Sohn2019-08-081-0/+5
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-5.3: Fix OpenSshConfigTest#config FileSnapshot: fix bug with timestamp thresholding In LockFile#waitForStatChange wait in units of file time resolution Cache FileStoreAttributeCache per directory Fix FileSnapshot#save(long) and FileSnapshot#save(Instant) Persist minimal racy threshold and allow manual configuration Measure minimum racy interval to auto-configure FileSnapshot Reuse FileUtils to recursively delete files created by tests Fix FileAttributeCache.toString() Add test for racy git detection in FileSnapshot Repeat RefDirectoryTest.testGetRef_DiscoversModifiedLoose 100 times Fix org.eclipse.jdt.core.prefs of org.eclipse.jgit.junit Add missing javadoc in org.eclipse.jgit.junit Enhance RepeatRule to report number of failures at the end Fix FileSnapshotTests for filesystem with high timestamp resolution Retry deleting test files in FileBasedConfigTest Measure filesystem timestamp resolution already in test setup Refactor FileSnapshotTest to use NIO APIs Measure stored timestamp resolution instead of time to touch file Handle CancellationException in FileStoreAttributeCache Fix FileSnapshot#saveNoConfig Use Instant for smudge time in DirCache and DirCacheEntry Use Instant instead of milliseconds for filesystem timestamp handling Workaround SecurityException in FS#getFsTimestampResolution Fix NPE in FS$FileStoreAttributeCache.getFsTimestampResolution FS: ignore AccessDeniedException when measuring timestamp resolution Add debug trace for FileSnapshot Use FileChannel.open to touch file and set mtime to now Persist filesystem timestamp resolution and allow manual configuration Increase bazel timeout for long running tests Bazel: Fix lint warning flagged by buildifier Update bazlets to latest version Bazel: Add missing dependencies for ArchiveCommandTest Bazel: Remove FileTreeIteratorWithTimeControl from BUILD file Add support for nanoseconds and microseconds for Config#getTimeUnit Optionally measure filesystem timestamp resolution asynchronously Delete unused FileTreeIteratorWithTimeControl FileSnapshot#equals: consider UNKNOWN_SIZE Timeout measuring file timestamp resolution after 2 seconds Fix RacyGitTests#testRacyGitDetection Change RacyGitTests to create a racy git situation in a stable way Deprecate Constants.CHARACTER_ENCODING in favor of StandardCharsets.UTF_8 Fix non-deterministic hash of archives created by ArchiveCommand Update Maven plugins ecj, plexus, error-prone Update Maven plugins and cleanup Maven warnings Make inner classes static where possible Fix API problem filters Change-Id: Iec3ad6ccc194582cb844310dc172c3103dae4457 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * Measure minimum racy interval to auto-configure FileSnapshotMatthias Sohn2019-08-061-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By running FileSnapshotTest#detectFileModified we found that the sum of measured filesystem timestamp resolution and measured clock resolution may yield a too small interval after a file has been modified which we need to consider racily clean. In our tests we didn't find this behavior on all systems we tested on, e.g. on MacOS using APFS and Java 8 and 11 this effect was not observed. On Linux (SLES 15, kernel 4.12.14-150.22-default) we collected the following test results using Java 8 and 11: In 23-98% of 10000 test runs (depending on filesystem type and Java version) the test failed, which means the effective interval which needs to be considered racily clean after a file was modified is larger than the measured file timestamp resolution. "delta" is the observed interval after a file has been modified but FileSnapshot did not yet detect the modification: "resolution" is the measured sum of file timestamp resolution and clock resolution seen in Java. Java version filesystem failures resolution min delta max delta 1.8.0_212-b04 btrfs 98.6% 1 ms 3.6 ms 6.6 ms 1.8.0_212-b04 ext4 82.6% 3 ms 1.1 ms 4.1 ms 1.8.0_212-b04 xfs 23.8% 4 ms 3.7 ms 3.9 ms 1.8.0_212-b04 zfs 23.1% 3 ms 4.8 ms 5.0 ms 11.0.3+7 btrfs 98.1% 3 us 0.7 ms 4.7 ms 11.0.3+7 ext4 98.1% 6 us 0.7 ms 4.7 ms 11.0.3+7 xfs 98.5% 7 us 0.1 ms 8.0 ms 11.0.3+7 zfs 98.4% 7 us 0.7 ms 5.2 ms Mac OS 1.8.0_212 APFS 0% 1 s 11.0.3+7 APFS 0% 6 us The observed delta is not distributed according to a normal gaussian distribution but rather random in the observed range between "min delta" and "max delta". Run this test after measuring file timestamp resolution in FS.FileAttributeCache to auto-configure JGit since it's unclear what mechanism is causing this effect. In FileSnapshot#isRacyClean use the maximum of the measured timestamp resolution and the measured "delta" as explained above to decide if a given FileSnapshot is to be considered racily clean. Add a 30% safety margin to ensure we are on the safe side. Change-Id: I1c8bb59f6486f174b7bbdc63072777ddbe06694d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * Add debug trace for FileSnapshotMatthias Sohn2019-07-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | Checking lastModified is time critical hence debug trace is the only way to analyze issues since debugging is impractical. Also add configuration for buffering of log4j output to reduce runtime impact when debug trace is on. Limit buffer to 1MiB and comment this configuration out since we may not always want to use buffering. Change-Id: Ib1a0537b67c8dc3fac994a77b42badd974ce6c97 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Support reading and writing cookies.Konrad Windszus2019-06-064-0/+13
| | | | | | | | | | | | | | | | | | The git config entries "http.cookieFile" and "http.saveCookies" are correctly evaluated. Bug: 488572 Change-Id: Icfeeea95e1a5bac3fa4438849d4ac2306d7d5562 Signed-off-by: Konrad Windszus <konrad_w@gmx.de> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Apache MINA sshd clientThomas Wolf2018-11-1336-381/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new ssh client implementation based on Apach MINA sshd 2.0.0. This implementation uses JGit's own config file parser and host entry resolver. Code inspection of the Apache MINA implementation revealed a few bugs or idiosyncrasies that immediately would re-introduce bugs already fixed in the past in JGit. Apache MINA sshd is not without quirks either, and I had to configure and override more than I had expected. But at least it was all doable in clean ways. Apache MINA boasts support for Bouncy Castle, so in theory this should open the way to using more ssh key algorithms, such as ed25519. The implementation is in a separate bundle and is still not used in the core org.eclipse.jgit bundle. The tests re-use the ssh tests from the core test bundle. Bug: 520927 Change-Id: Ib35e73c35799140fe050d1ff4fb18d0d3596580e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* | Add more ssh tests: pushing, known_host file handling, etc.Thomas Wolf2018-11-1338-16/+381
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for git-receive-pack to the ssh git server and add two new tests for pushing. This actually uncovered an undocumented requirement in TransportSftp: the FTP rename operation assumes POSIX semantics, i.e., that the target is removed. This works as written only for servers that support and advertise the "posix-rename@openssh.com" FTP extension. Our little Apache MINA server does not advertise this extension. Fix the FtpChannel implementation for Jsch to handle this case in a meaningful way so that it can pass the new "push over sftp" test. Add more tests to test the behavior of server host key checking. Also refactor the tests generally to separate better the test framework from the actual tests. Bug: 520927 Change-Id: Ia4bb85e17ddacde7b36ee8c2d5d454bbfa66dfc3 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* | Ssh tests with an Apache MINA sshd test git serverThomas Wolf2018-11-062-0/+16
|/ | | | | | | | | | | | | | | | Add a simple ssh git server based on Apache MINA sshd, and use it in new tests that verify ssh operations and in particular a number of bugs that had cropped up over time in JSch. The git server supports fetching only, and sftp access. The tests are all in an abstract base class; the concrete JschSshTest class only provides ssh-specific test setup. So the same tests could be run easily also with some other ssh client. Bug: 520927 Change-Id: Ide6687b717fb497a29fc83f22b07390a26dfce1d Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Support -merge attribute in binary macroMathieu Cartaud2017-06-272-0/+0
| | | | | | | | | | | | | | The merger is now able to react to the use of the merge attribute. The value unset and the custom value 'binary' are handled (-merge and merge=binary) Since the specification of the merge attribute states that when the attribute is unset, ours version must be kept in case of a conflict, we don't overwrite the file but keep the local version. Bug: 517128 Change-Id: Ib5fbf17bdaf727bc5d0e106ce88f2620d9f87a6f Signed-off-by: Mathieu Cartaud <mathieu.cartaud@obeo.fr>
* SHA-1: collision detection supportShawn Pearce2017-02-282-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update SHA1 class to include a Java port of sha1dc[1]'s ubc_check, which can detect the attack pattern used by the SHAttered[2] authors. Given the shattered example files that have the same SHA-1, this modified implementation can identify there is risk of collision given only one file in the pair: $ jgit ... [main] WARN org.eclipse.jgit.util.sha1.SHA1 - SHA-1 collision 38762cf7f55934b34d179ae6a4c80cadccbb7f0a When JGit detects probability of a collision the SHA1 class now warns on the logger, reporting the object's SHA-1 hash, and then throws a Sha1CollisionException to the caller. From the paper[3] by Marc Stevens, the probability of a false positive identification of a collision is about 14 * 2^(-160), sufficiently low enough for any detected collision to likely be a real collision. git-core[4] may adopt sha1dc before the system migrates to an entirely new hash function. This commit enables JGit to remain compatible with that move to sha1dc, and help protect users by warning if similar attacks as SHAttered are identified. Performance declined about 8% (detection off), now: MessageDigest 238.41 MiB/s MessageDigest 244.52 MiB/s MessageDigest 244.06 MiB/s MessageDigest 242.58 MiB/s SHA1 216.77 MiB/s (was ~240.83 MiB/s) SHA1 220.98 MiB/s SHA1 221.76 MiB/s SHA1 221.34 MiB/s This decline in throughput is attributed to the step loop unrolling in compress(), which was necessary to easily fit the UbcCheck logic into the hash function. Using helper functions s1-s4 reduces the code explosion, providing acceptable throughput. With detection enabled (default): SHA1 detectCollision 180.12 MiB/s SHA1 detectCollision 181.59 MiB/s SHA1 detectCollision 181.64 MiB/s SHA1 detectCollision 182.24 MiB/s sha1dc (native C) ~206.28 MiB/s sha1dc (native C) ~204.47 MiB/s sha1dc (native C) ~203.74 MiB/s Average time across 100,000 calls to hash 4100 bytes (such as a commit or tree) for the various algorithms available to JGit also shows SHA1 is slower than MessageDigest, but by an acceptable margin: MessageDigest 17 usec SHA1 18 usec SHA1 detectCollision 22 usec Time to index-pack for git.git (217982 objects, 69 MiB) has increased: MessageDigest SHA1 w/ detectCollision ------------- ----------------------- 20.12s 25.25s 19.87s 25.48s 20.04s 25.26s avg 20.01s 25.33s +26% Being implemented in Java with these additional safety checks is clearly a penalty, but throughput is still acceptable given the increased security against object name collisions. [1] https://github.com/cr-marcstevens/sha1collisiondetection [2] https://shattered.it/ [3] https://marc-stevens.nl/research/papers/C13-S.pdf [4] https://public-inbox.org/git/20170223230621.43anex65ndoqbgnf@sigill.intra.peff.net/ Change-Id: I9fe4c6d8fc5e5a661af72cd3246c9e67b1b9fee6
* Fix symlink content comparison on MacOS in tree walkThomas Wolf2016-10-111-0/+30
| | | | | | | | | | | | | | | | | | | | | | | Symlinks on MacOS are written as UTF-8 NFD, but readSymbolicLink().toString() converts to NFC with potentially fewer bytes. May occur in particular if the link target has non-ASCII characters for which the NFC and NFD encodings differ. This may lead to an EOFException: Short read of block. This causes all kinds of weird effects in EGit, ranging from failing rebases (which report the exception to the user) to EGit decorations in the navigator silently disappearing (and never coming back). * Rename readContentAsNormalizedString() to readSymlinkTarget() as it's called only for symlinks. Also make it protected. * Fix by allowing the read to succeed even if less than the expected number of bytes are returned by the entry's input stream. * Override in FileTreeIterator to use fs.readSymlink() directly. Includes a new MacOS-only test. Change-Id: I264c5972d67b1cbb1ed690580f5706e671b9affd Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Allow setting FileMode to executable when applying patches in ApplyCommandNadav Cohen2016-05-178-0/+40
| | | | | | | | | git-apply allows modifying file modes in patched files using either "new mode" or "new file mode" headers. This patch adds support for setting files as executables and vice-versa. Change-Id: I24848966b46f686f540a8efa8150b42e0d9c3ad1 Signed-off-by: Nadav Cohen <nadavcoh@gmail.com>
* Fix ApplyCommand when result of patch is an empty fileJon Schneider2016-04-163-0/+8
| | | | | | | | | | Such hunks are identifiable by a zero value for "new start line". Prior to the fix, JGit throws and ArrayIndexOutOfBoundsException on such patches. Change-Id: I4f3deb5e5f41a08af965fcc178d678c77270cddb Signed-off-by: Jonathan Schneider <jkschneider@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix apply patch which did not work with non-ascii charactersXinTong Wang2016-03-0313-0/+48
| | | | | | Bug: 483943 Change-Id: If28f64053d20ab1bee54245f223e952dc2fe392c Signed-off-by: XinTong Wang <xintong@ca.ibm.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Adding JGitV1 and JGitV2 Walk EncryptionAndrei Pozolotin2015-10-183-0/+73
| | | | | | | | | | | | | | | Building on top of https://git.eclipse.org/r/#/c/56391/ Here we preserve compatibility with JetS3t and add 2 new native JGit encryption implementations. For reference, see connection configuration files: * Version 0: jgit-s3-connection-v-0.properties * Version 1: jgit-s3-connection-v-1.properties * Version 2: jgit-s3-connection-v-2.properties Change-Id: I713290bcacbe92d88e5ef28ce137de73dd1abe2f Signed-off-by: Andrei Pozolotin <andrei.pozolotin@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Adding AES Walk Encryption support in http://www.jets3t.org/ modeAndrei Pozolotin2015-10-184-0/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See previous attempt: https://git.eclipse.org/r/#/c/16674/ Here we preserve as much of JetS3t mode as possible while allowing to use new Java 8+ PBE algorithms such as PBEWithHmacSHA512AndAES_256 Summary of changes: * change pom.xml to control long tests * add WalkEncryptionTest.launch to run long tests * add AmazonS3.Keys to to normalize use of constants * change WalkEncryption to support AES in JetS3t mode * add WalkEncryptionTest to test remote encryption pipeline * add support for CI configuration for live Amazon S3 testing * add log4j based logging for tests in both Eclipse and Maven build To test locally, check out the review branch, then: * create amazon test configuration file * located your home dir: ${user.home} * named jgit-s3-config.properties * file format follows AmazonS3 connection settings file: accesskey = your-amazon-access-key secretkey = your-amazon-secret-key test.bucket = your-bucket-for-testing * finally: * run in Eclipse: WalkEncryptionTest.launch * or * run in Shell: mvn test --define test=WalkEncryptionTest Change-Id: I6f455fd9fb4eac261ca73d0bec6a4e7dae9f2e91 Signed-off-by: Andrei Pozolotin <andrei.pozolotin@gmail.com>
* Fix patch application WRT windows line endings.Markus Duft2013-01-193-0/+18
| | | | | | | | | | | | Previously the result of an application would have been \r\r\n in the case of windows line endings, as RawText does not touch the \r, and ApplyCommand adds "\r\n" if this is the ending of the first line in the target file. Only always adding \n should be ok, since \r\n would be the result if the file and the patch include windows line endings. Also add according test. Change-Id: Ibd4c4948d81bd1c511ecf5fd6c906444930d236e
* Make ApplyCommand create missing parent directories for new filesMarkus Duft2012-07-161-0/+9
| | | | | | | | | | Otherwise applying will fail with a FileNotFoundException, because File.createNewFile() fails with missing parents. Contains change & according test. Change-Id: I970522b549b8bb260ca6720da11f12c57ee8a492 Signed-off-by: Chris Aniszczyk <zx@twitter.com>
* Ignore trailing comments in transport SPI parsingKevin Sawicki2012-03-211-0/+7
| | | | | | | | | | Check for a '#' character in each line read and parse the leading characters as the class name of a TransportProtocol being registered via SPI. Bug: 373439 Change-Id: If36cb62c07ecea78ba0f326a87edf1d80b7b42b6 Signed-off-by: Chris Aniszczyk <zx@twitter.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 19:12:17 +0000