aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit/src/org/eclipse/jgit/util/io/AutoLFInputStream.java
Commit message (Collapse)AuthorAgeFilesLines
* Remove deprecated AutoLFInputStream constructorsMatthias Sohn2024-09-031-38/+0
| | | | Change-Id: I00241e45d947582886658fa528cc20a961fed9e6
* Fix all Javadoc warnings and fail on themAntoine Musso2023-06-161-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Binary and CR-LF detection: lone CRs -> binaryThomas Wolf2021-10-311-2/+2
| | | | | | | | | | | | | | | | | | | C git considers not only files containing NUL bytes as binary but also files containing lone CRs. Implement this also for JGit. C git additionally counts printable vs. non-printable characters and considers files that have non_printable_count > printable_count / 128 also as binary. This is not implemented because such counting probably only makes sense if one looks at the full file or blob content. The Auto[CR]LF* streams in JGit look only at the first few KiB of a stream in order not to buffer too much. For the C git implementation, see [1]. [1] https://github.com/git/git/blob/7e27bd589d/convert.c#L35 Bug: 576971 Change-Id: Ia169b59bdbf1477f32ee2014eeb8406f81d4b1ab Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Make the buffer size for text/binary detection configurableThomas Wolf2021-10-301-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | The various streams used in JGit for text/binary and CR-LF detection used different buffer sizes. Most used 8000, but one used 8KiB, and one used 8096 (SIC!) bytes. Considering only the first 8kB of a file/blob is not sufficient; it may give behavior incompatible with C git. C git considers the whole blob; since it uses memory-mapped files it can do so with acceptable performance. Doing this in JGit would most likely incur a noticeable performance penalty. But 8kB is a bit small; in the file in bug 576971 the limit was hit before the first CR-LF, which occurred on line 155 at offset 9759 in the file. Make RawText.FIRST_FEW_BYTES only a default and minimum setting, and set it to 8KiB. Make the actual buffer size configurable: provide static methods getBufferSize() and setBuffersize(), and use getBufferSize() throughout instead of the constant. This enables users of the JGit library to set their own possibly larger buffer size. Bug: 576971 Change-Id: I447762c9a5147a521f73d2864ba59ed89f555d54 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Keep line endings for text files committed with CR/LF on text=autoThomas Wolf2020-08-171-14/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Git never converts line endings if the version in the repository is a text file with CR/LF and text=auto. See [1]: "When the file has been committed with CRLF, no conversion is done." Because the sentence just before is about converting line endings on check-in, I had understood that in commit 60cf85a [2] to mean that no conversion on check-in was to be done. However, as bug 565048 and a code inspection of the C git code showed it really means no conversion is done on check-in *or check-out*. If the text attribute is not set but core.autocrlf = true, this is the same as text=auto eol=crlf. C git does not convert on check-out even on text=auto eol=lf if the index version is a text file with CR/LF. For check-in, one has to look at the intended target, which is done in WorkingTreeIterator since commit 60cf85a. For check-out, it can be done by looking at the source and can thus be done in the AutoLFOutputStream. Additionally, provide a constructor for AutoLFInputStream to do the same; for cases where the equivalent of a check-out is done via an input stream obtained from a blob. (EGit does that in its GitBlobStorage for the Eclipse compare framework; it's more efficient than using a TemporaryBuffer and DirCacheCheckout.getContent(), and it avoids the need for a temporary file.) Adapt existing tests, and add new checkout and merge tests to verify the resulting files have the correct line endings. EGit's GitBlobStorage will need to call the new version of EolStreamTypeUtil.wrapInputStream(). [1] https://git-scm.com/docs/gitattributes#Documentation/gitattributes.txt-Settostringvalueauto [2] https://git.eclipse.org/r/c/jgit/jgit/+/127324 Bug: 565048 Change-Id: If1282ef43e2abd00263541bd10a01fe1f5c619fc Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* 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 core.autocrlf for non-normalized indexThomas Wolf2019-02-261-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With text=auto or core.autocrlf=true, git does not normalize upon check-in if the file in the index contains already CR/LFs. The documentation says: "When text is set to "auto", the path is marked for automatic end-of-line conversion. If Git decides that the content is text, its line endings are converted to LF on checkin. When the file has been committed with CRLF, no conversion is done."[1] Implement the last bit as in canonical git: check the blob in the index for CR/LFs. For very large files, we check only the first 8000 bytes, like RawText.isBinary() and AutoLFInputStream do. In Auto(CR)LFInputStream, ensure that the buffer is filled as much as possible for the isBinary() check. Regarding these content checks, there are a number of inconsistencies: * Canonical git considers files containing lone CRs as binary. * RawText checks the first 8000 bytes. * Auto(CR)LFInputStream checks the first 8096 (not 8192!) bytes. None of these are changed with this commit. It appears that canonical git will check the whole blob, not just the first 8k bytes. Also note: the check for CR/LF text won't work with LFS (neither in JGit nor in git) since the blob data is not run through the smudge filter. C.f. [2]. Two tests in AddCommandTest actually tested that normalization was done even if the file was already committed with CR/LF.These tests had to be adapted. I find the git documentation unclear about the case where core.autocrlf=input, but from [3] it looks as if this non-normalization also applies in this case. Add new tests in CommitCommandTest testing this for the case where the index entry is for a merge conflict. In this case, canonical git uses the "ours" version.[4] Do the same. [1] https://git-scm.com/docs/gitattributes [2] https://github.com/git/git/blob/3434569fc/convert.c#L225 [3] https://github.com/git/git/blob/3434569fc/convert.c#L529 [4] https://github.com/git/git/blob/f2b6aa98b/read-cache.c#L3281 Bug: 470643 Change-Id: Ie7310539fbe6c737d78b1dcc29e34735d4616b88 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Remove 'final' in parameter listsHan-Wen Nienhuys2018-05-151-1/+1
| | | | | Change-Id: Id924f79c8b2c720297ebc49bf9c5d4ddd6d52547 Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
* Fix javadoc in org.eclipse.jgit util packagesMatthias Sohn2017-12-201-1/+6
| | | | Change-Id: Ia655f45153bcf1d422ffffce6dcf914847e14c4c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Add EOL stream type detection to TreeWalkIvan Motsch2016-03-071-0/+199
TreeWalk provides the new method getEolStreamType. This new method can be used with EolStreamTypeUtil in order to create a wrapped InputStream or OutputStream when reading / writing files. The implementation implements support for the git configuration options core.crlf, core.eol and the .gitattributes "text", "eol" and "binary" CQ: 10896 Bug: 486563 Change-Id: Ie4f6367afc2a6aec1de56faf95120fff0339a358 Signed-off-by: Ivan Motsch <ivan.motsch@bsiag.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-10 19:08:18 +0000