aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test/tst-rsrc/org/eclipse/jgit
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>
* 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>
* 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>
* 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>
* 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>
* Add ApplyCommand to JGit APITomasz Zarna2012-03-0410-0/+99
| | | | | | | Bug: 361548 CQ: 6243 Change-Id: I08e1369e142bb19f42a8d7bbb5a7d062cc8533fc Signed-off-by: Chris Aniszczyk <zx@twitter.com>
* Fix TestTranslationBundleRobin Rosenberg2010-12-314-0/+4
| | | | | | | | | | | The test was never run from maven, because its name did not end in a way that was recognized by the pom. After rename it failed because it did not find its resources. Rename test class and move resources to the resources folder Change-Id: I74a7ef1373cd902e1d05ff6ea38f8648b5fc5700 Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
* Fix ArrayIndexOutOfBoundsException in DirCacheIteratorShawn O. Pearce2010-12-221-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the 'TREE' extension contains an invalid subtree that has been removed, DirCacheIterator still tried to access it due to an invalid childCnt field within the parent DirCacheTree object. This is easy for a user to do, they just need to move all files out of a subdirectory. For example, the input for the JUnit test case for this bug was built using the following C Git sequence: mkdir -p a/b touch a/b/c q git add a/b/c q git write-tree git mv a/b/c a/a After the last step, the subdirectory a/b is empty, as its only file was moved into the parent directory. Because of the earlier `git write-tree` operation, there is a 'TREE' extension present, but the a and a/b subdirectories have been marked invalid by the rename. When JGit tried to iterate over the a tree, it tried to correct childCnt to be zero as a/b no longer exists, but it failed to update childCnt. Change-Id: I7a0f78fc48a36b1a83252d354618f6807fca0426 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Extend DirCache test case to check "intent to add" flag.Marc Strapetz2010-08-311-0/+0
|
* Partial support for index file format "3".Marc Strapetz2010-08-311-0/+0
| | | | | | | | Extended flags are processed and available via DirCacheEntry's new isSkipWorkTree() and isIntentToAdd() methods. "resolve-undo" information is completely ignored since its an optional extension. Change-Id: Ie6e9c6784c9f265ca3c013c6dc0e6bd29d3b7233
* Move ignore node handling into WorkingTreeIteratorShawn O. Pearce2010-07-219-4/+0
| | | | | | | | | | | | | | | The working tree iterator has perfect knowledge of the path structure as well as immediate information about whether or not an ignore file even exists at this level. We can exploit that to simplify the logic and running time for testing ignored file status by pushing all of the checks down into the iterator itself. Change-Id: I22ff534853e8c5672cc5c2d9444aeb14e294070e Signed-off-by: Shawn O. Pearce <spearce@spearce.org> CC: Charley Wang <chwang@redhat.com> CC: Chris Aniszczyk <caniszczyk@gmail.com> CC: Stefan Lay <stefan.lay@sap.com> CC: Matthias Sohn <matthias.sohn@sap.com>
* Add compatibility with gitignore specificationsCharley Wang2010-07-1311-0/+8
| | | | | | | | | | | | | | | This patch adds ignore compatibility to jgit. It encompasses exclude files as well as .gitignore. Uses TreeWalk and FileTreeIterator to find nodes and parses .gitignore files when required. The patch includes a simple cache that can be used to save results and avoid excessive gitignore parsing. CQ: 4302 Bug: 303925 Change-Id: Iebd7e5bb534accca4bf00d25bbc1f561d7cad11b Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com> Signed-off-by: Stefan Lay <stefan.lay@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Correctly skip over unrecognized optional dircache extensionsShawn O. Pearce2010-02-023-0/+0
| | | | | | | | | | | | | | | | | | | We didn't skip the correct number of bytes when we skipped over an unrecognized but optional dircache extension. We missed skipping the 8 byte header that makes up the extension's name and length. We also didn't include the skipped extension's payload as part of our index checksum, resuting in a checksum failure when the index was done reading. So ensure we always scan through a skipped section and include it in the checksum computation. Add a test case for a currently unsupported index extension, 'ZZZZ', to verify we can still read the DirCache object even though we don't know what 'ZZZZ' is supposed to mean. Bug: 301287 Change-Id: I4bdde94576fffe826d0782483fd98cab1ea628fa Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Added -crfl attribute for DiffFormatterReflowTest test dataConstantine Plotnikov2009-12-271-0/+3
| | | | | | | | | | | The test data is expected to have unix new lines by tests, but it is converted to crlf on Windows platform (with msys git). As result DiffFormatterReflowTest tests fail. To prevent this problem, crlf conversion is disbled for test data related to that test. Bug: 295077 Change-Id: I67d3ed543fcc38647041896146de12b1781ec6be Signed-off-by: Constantine Plotnikov <constantine.plotnikov@gmail.com>
* Initial JGit contribution to eclipse.orgGit Development Community2009-09-2963-0/+2977
Per CQ 3448 this is the initial contribution of the JGit project to eclipse.org. It is derived from the historical JGit repository at commit 3a2dd9921c8a08740a9e02c421469e5b1a9e47cb. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 19:00:28 +0000