aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit/src/org/eclipse/jgit/api/ApplyCommand.java
Commit message (Collapse)AuthorAgeFilesLines
* Fix all Javadoc warnings and fail on themAntoine Musso2023-06-161-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes all the javadoc warnings, stops ignoring doclint 'missing' category and fails the build on javadoc warnings for public and protected classes and class members. Since javadoc doesn't allow access specifiers when specifying doclint configuration we cannot set `-Xdoclint:all,-missing/private` hence there is no simple way to skip private elements from doclint. Therefore we check javadoc using the Eclipse Java compiler (which is used by default) and javadoc configuration in `.settings/org.eclipse.jdt.core.prefs` files. This allows more fine grained configuration. We can reconsider this when javadoc starts supporting access specifiers in the doclint configuration. Below are detailled explanations for most modifications. @inheritDoc =========== doclint complains about explicits `{@inheritDoc}` when the parent does not have any documentation. As far as I can tell, javadoc defaults to inherit comments and should only be used when one wants to append extra documentation from the parent. Given the parent has no documentation, remove those usages which doclint complains about. In some case I have moved up the documentation from the concrete class up to the abstract class. Remove `{@inheritDoc}` on overriden methods which don't add additional documentation since javadoc defaults to inherit javadoc of overridden methods. @value to @link =============== In PackConfig, DEFAULT_SEARCH_FOR_REUSE_TIMEOUT and similar are forged from Integer.MAX_VALUE and are thus not considered constants (I guess cause the value would depends on the platform). Replace it with a link to `Integer.MAX_VALUE`. In `StringUtils.toBoolean`, @value was used to refer to the `stringValue` parameter. I have replaced it with `{@code stringValue}`. {@link <url>} to <a> ==================== @link does not support being given an external URL. Replaces them with HTML `<a>`. @since: being invalid ===================== org.eclipse.jgit/src/org/eclipse/jgit/util/Equality.java has an invalid tag `@since: ` due to the extra `:`. Javadoc does not complain about it with version 11.0.18+10 but does with 11.0.19.7. It is invalid regardless. invalid HTML syntax =================== - javadoc doesn't allow <br/>, <p/> and </p> anymore, use <br> and <p> instead - replace <tt>code</tt> by {@code code} - <table> tags don't allow summary attribute, specify caption as <caption>caption</caption> to fix this doclint visibility issue ======================== In the private abstract classes `BaseDirCacheEditor` and `BasePackConnection` links to other methods in the abstract class are inherited in the public subclasses but doclint gets confused and considers them unreachable. The HTML documentation for the sub classes shows the relative links in the sub classes, so it is all correct. It must be a bug somewhere in javadoc. Mute those warnings with: @SuppressWarnings("doclint:missing") Misc ==== Replace `<` and `>` with HTML encoded entities (`&lt; and `&gt;`). In `SshConstants` I went enclosing a serie of -> arrows in @literal. Additional tags =============== Configure maven-javad0c-plugin to allow the following additional tags defined in https://openjdk.org/jeps/8068562: - apiNote - implSpec - implNote Missing javadoc =============== Add missing @params and descriptions Change-Id: I840056389aa59135cfb360da0d5e40463ce35bd0 Also-By: Matthias Sohn <matthias.sohn@sap.com>
* Fix PatchApplier error handling.Nitzan Gur-Furman2023-03-281-4/+30
| | | | | | | | | | | | | | | | 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
* Split out ApplyCommand logic to PatchApplier classNitzan Gur-Furman2022-09-151-665/+14
| | | | | | | | | | | | | | PatchApplier now routes updates through the index. This has two results: * we can now execute patches in-memory. * the JGit apply command will now always update the index to match the working tree. Change-Id: Id60a88232f05d0367787d038d2518c670cdb543f Co-authored-by: Han-Wen Nienhuys <hanwen@google.com> Co-authored-by: Nitzan Gur-Furman <nitzan@google.com>
* WorkTreeUpdater: use DirCacheCheckout#StreamSupplierHan-Wen Nienhuys2022-09-061-6/+2
| | | | | | This avoids having to introduce the StreamLoader bridging class. Change-Id: I98de155c458745236df24d6323eabed5061e7f8c
* DirCacheCheckout#getContent: also take InputStream supplierHan-Wen Nienhuys2022-09-061-4/+2
| | | | | | | | | | | | | | | | | This lets us use DirCacheCheckout for routines that want to write files in the worktree that aren't available as a git object. DirCacheCheckout#getContent takes a InputStream supplier rather than InputStream: if filtering fails with IOException, the data is placed unfiltered in the checkout. This means that the stream has to be read again, from the start. Use it in this way in ApplyCommand. This use is incorrect, though: the same InputStream is returned twice, so if the read to be retried, the stream will return 0 bytes. It doesn't really matter, because in either case, the SHA1 will not match up, and the patch fails. Change-Id: I2efa9a6da06806ff79b155032fe4b34be8fec09e
* ApplyCommand: fix ApplyResult#updatedFilesHan-Wen Nienhuys2022-08-231-5/+6
| | | | | | | | On executing a copy, mark the destination as updated. On executing a rename, mark both source and destination as updated. Change-Id: Ied5b9b0e5a14eac59a06cdd0961e25e143f50ff0
* Reapply "Create util class for work tree updating in both filesystem and index."Nitzan Gur-Furman2022-08-081-65/+7
| | | | | | | | | | | | | | | | | | | | | This reverts commit 5709317f71ccaf26eceaa896150f203879b634b8. Add a bugfix for deletions in ResolveMergers instantiated with just an ObjectInserter as argument. Original change description: Create util class for work tree updating in both filesystem and index. This class intends to make future support in index updating easier. This class currently extracts some logic from ResolveMerger. Logic related to StreamSupplier was copied from ApplyCommand, which will be integrated in a following change. Co-authored-by: Nitzan Gur-Furman <nitzan@google.com> Co-authored-by: Han-Wen Nienhuys <hanwen@google.com> Change-Id: Ideaefd51789a382a8b499d1ca7ae0146d032f48b
* Revert "Create util class for work tree updating in both filesystem and index."Jonathan Nieder2022-08-051-7/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 5151b324f4605b1091ac5843dcc1f04b3996f0d1. It is producing NullPointerExceptions during merges, causing Gerrit's acceptance tests to fail: com.google.gerrit.extensions.restapi.RestApiException: Cannot rebase ps [...] at com.google.gerrit.server.api.changes.RevisionApiImpl.rebase(RevisionApiImpl.java:280) at com.google.gerrit.acceptance.api.change.ChangeIT.rebaseChangeBase(ChangeIT.java:1584) Caused by: com.google.gerrit.server.update.UpdateException: java.lang.NullPointerException: repository is required at com.google.gerrit.server.update.BatchUpdate.executeUpdateRepo(BatchUpdate.java:588) [...] Caused by: java.lang.NullPointerException: repository is required at org.eclipse.jgit.merge.Merger.nonNullRepo(Merger.java:128) at org.eclipse.jgit.merge.ResolveMerger.addDeletion(ResolveMerger.java:380) at org.eclipse.jgit.merge.ResolveMerger.processEntry(ResolveMerger.java:553) at org.eclipse.jgit.merge.ResolveMerger.mergeTreeWalk(ResolveMerger.java:1224) at org.eclipse.jgit.merge.ResolveMerger.mergeTrees(ResolveMerger.java:1174) at org.eclipse.jgit.merge.ResolveMerger.mergeImpl(ResolveMerger.java:299) at org.eclipse.jgit.merge.Merger.merge(Merger.java:233) at org.eclipse.jgit.merge.Merger.merge(Merger.java:186) at org.eclipse.jgit.merge.ThreeWayMerger.merge(ThreeWayMerger.java:96) at com.google.gerrit.server.change.RebaseChangeOp.rebaseCommit(RebaseChangeOp.java:360) Change-Id: Idf63de81666d0df118d2d93c4f6e014e00dc05b8
* Create util class for work tree updating in both filesystem and index.Nitzan Gur-Furman2022-07-251-65/+7
| | | | | | | | | | This class intends to make future support in index updating easier. This class currently extracts some logic from ResolveMerger. Logic related to StreamSupplier was copied from ApplyCommand, which will be integrated in a following change. Change-Id: I8dc5a582433fc9891038c628385d3970b5a8984b
* ApplyCommand: fix "no newline at end" detectionThomas Wolf2021-05-261-1/+5
| | | | | | | | | | | 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-261-2/+14
| | | | | | | | | | 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-261-38/+32
| | | | | | | | | | | | | | | | | | | | | 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-261-30/+244
| | | | | | | | | | | | | | 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: convert to git internal format before applying patchThomas Wolf2021-05-181-24/+255
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ApplyCommand: use context lines to determine hunk locationThomas Wolf2020-06-041-42/+124
| | | | | | | | | | | | | | 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>
* ApplyCommand: use Files#copy to copy fileMatthias Sohn2020-05-061-9/+4
| | | | | | This should be faster. Change-Id: I404ec5e66731b3cf7a8e621cf1ff8748d109ea69 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Apply hunks when renaming or copying from patch filesJack Wickham2020-05-061-3/+4
| | | | | | | | 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-061-0/+1
| | | | | | | | | | | | 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>
* Update EDL 1.0 license headers to new short SPDX compliant formatMatthias Sohn2020-01-041-38/+5
| | | | | | | | | | This is the format given by the Eclipse legal doc generator [1]. [1] https://www.eclipse.org/projects/tools/documentation.php?id=technology.jgit Bug: 548298 Change-Id: I8d8cabc998ba1b083e3f0906a8d558d391ffb6c4 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix ApplyCommand which doesn't work if patch adds empty fileAnton Khodos2019-08-191-3/+7
| | | | | | Bug: 548219 Change-Id: Ibb32132a38e54508a24489322da58ddfd80a1d9a Signed-off-by: Anton Khodos <khodosanton@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* SpotBugs: don't rely on default encodingMatthias Sohn2018-09-101-2/+6
| | | | Change-Id: Ic42f30c564270230fc629a917be85194d27d0338 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* ApplyCommand: Open FileWriter in try-with-resourceDavid Pursehouse2018-03-051-3/+3
| | | | | Change-Id: Ia473f74dc4608fc43edd57eda4f193c226e9004d Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Fix javadoc in org.eclipse.jgit annotations and api packagesMatthias Sohn2017-12-181-5/+4
| | | | Change-Id: I2761ea91f8dfed16ea54e7a6646af03a30c15ec9 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Enable and fix warnings about redundant specification of type argumentsDavid Pursehouse2017-02-201-3/+3
| | | | | | | | | | Since the introduction of generic type parameter inference in Java 7, it's not necessary to explicitly specify the type of generic parameters. Enable the warning in Eclipse, and fix all occurrences. Change-Id: I9158caf1beca5e4980b6240ac401f3868520aad0 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Enable and fix 'Should be tagged with @Override' warningDavid Pursehouse2017-02-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Set missingOverrideAnnotation=warning in Eclipse compiler preferences which enables the warning: The method <method> of type <type> should be tagged with @Override since it actually overrides a superclass method Justification for this warning is described in: http://stackoverflow.com/a/94411/381622 Enabling this causes in excess of 1000 warnings across the entire code-base. They are very easy to fix automatically with Eclipse's "Quick Fix" tool. Fix all of them except 2 which cause compilation failure when the project is built with mvn; add TODO comments on those for further investigation. Change-Id: I5772061041fd361fe93137fd8b0ad356e748a29c Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Allow setting FileMode to executable when applying patches in ApplyCommandNadav Cohen2016-05-171-0/+3
| | | | | | | | | 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-161-6/+12
| | | | | | | | | | 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-031-4/+6
| | | | | | Bug: 483943 Change-Id: If28f64053d20ab1bee54245f223e952dc2fe392c Signed-off-by: XinTong Wang <xintong@ca.ibm.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Rename files using NIO2 atomic renameMatthias Sohn2015-12-301-2/+7
| | | | | Bug: 319233 Change-Id: I5137212f5cd3195a52f90ed5e4ce3cf194a13efd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix patch application WRT windows line endings.Markus Duft2013-01-191-7/+4
| | | | | | | | | | | | 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
* Do not perform character translation on copies in patchesRobin Rosenberg2012-12-271-3/+8
| | | | | | | Translation is unnecessary and risks damaging the file. Also ensure that we close the file if an I/O error occurs. Change-Id: Ieae6eb941fdeaa61f2611f4cd14dd39117aa12f9
* Mark non-externalizable strings as suchRobin Rosenberg2012-12-271-3/+3
| | | | | | | | | | A few classes such as Constanrs are marked with @SuppressWarnings, as are toString() methods with many liternal, but otherwise $NLS-n$ is used for string containing text that should not be translated. A few literals may fall into the gray zone, but mostly I've tried to only tag the obvious ones. Change-Id: I22e50a77e2bf9e0b842a66bdf674e8fa1692f590
* Make ApplyCommand create missing parent directories for new filesMarkus Duft2012-07-161-0/+2
| | | | | | | | | | 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>
* Further cleanup of exceptions in Git APIRobin Rosenberg2012-06-051-1/+5
| | | | | | | | | - Translate internal exceptions to corresponding API exception - Do not catch GitAPI exceptions internally to an internal exception. Just pass them to caller - Mention thrown exceptions in javadoc Change-Id: I9044cf86d2b0bcc8b63b7cc016e1bf0055a62053 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Add missing @since tags to mark API added in 2.0Matthias Sohn2012-05-101-0/+1
| | | | | | Change-Id: I0a86ce0e393dfde9bb27f0b29e036e76c856396e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Chris Aniszczyk <zx@twitter.com>
* Move JGitText to an internal packageRobin Rosenberg2012-03-121-1/+1
| | | | Change-Id: I763590a45d75f00a09097ab6f89581a3bbd3c797
* RawText#getEOL() does the same thing as RawText#getLineDelimiter()Tomasz Zarna2012-03-051-1/+1
| | | | | | | | | The duplication has been introduced when merging I08e1369e142bb19f42a8d7bbb5a7d062cc8533fc and I18adc63596f4657516ccc6d704a561924c79d445. The former should have been manually rebased. It also missed a copyright update in ApplyCommandTest. Change-Id: I18fe6108220f964524fb16b719604222aa7abee6
* Add ApplyCommand to JGit APITomasz Zarna2012-03-041-0/+258
Bug: 361548 CQ: 6243 Change-Id: I08e1369e142bb19f42a8d7bbb5a7d062cc8533fc Signed-off-by: Chris Aniszczyk <zx@twitter.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-31 18:15:31 +0000