aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test/tst/org/eclipse/jgit/util
Commit message (Collapse)AuthorAgeFilesLines
* RelativeDateFormatter: Use Instant instead of dateIvan Frade2024-12-231-4/+4
| | | | | | | | | Errorprone suggest to use the more modern java.time.Instant instead of the older Date API. Offer a variant of RelativeDateFormatter#format method for Instants. Change-Id: I536230327ec7b617958191fbe36f98b1294f6d2e
* RawParseUtils: Default to UTC in invalid timezonesIvan Frade2024-12-091-0/+15
| | | | | | | | | | | | | PersonIdent used to translate invalid timezones to UTC [1], but the new java.time code just throws an exception. Also the parsing used happen on demand, but now is done in the constructor, so the exception is thrown even if the timezone is not used at all. Check the parsed timezone and default to UTC if it is out of range. [1] https://docs.oracle.com/javase/8/docs/api/java/util/TimeZone.html#getTimeZone-java.lang.String- Change-Id: I90dd7d842ac8f44caef3b76d57375dead76bebde
* GitTimeParser: Fix multiple errorprone and style commentsIvan Frade2024-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This code came from GitDateParser and inherited these issues. It is a good time to fix them: * Use always {} in if and fors (eclipse guide) * Use the more efficient EnumMap for the formatters * variable.equals(CONSTANT) instead of CONSTANT.equals(var) https://errorprone.info/bugpattern/YodaCondition * private constructor to prevent instantiations of a utility classes https://errorprone.info/bugpattern/PrivateConstructorForUtilityClass * methods named in camelCase * Use string.split(..., int) https://errorprone.info/bugpattern/StringSplitter * Initialize variable in first use Change-Id: I0ae70ad9befc66fa9c057af135f2b0b2dab3869a
* RawParseUtils test: Use java.time to create PersonIdentsIvan Frade2024-11-191-16/+19
| | | | | | | | | | | | The constructor with long/int for time/tz is deprecated in favor of Instant/ZoneId. Update first the expectations in the tests to the new constructors, so we know we are creating the same PersonIdents than before. We update the code later, knowing there is no regression in e.g. format or precision. Change-Id: I05c759bdd4cf73b8afe79fae3c792f2f1300d1e6
* GitTimeParser: A date parser using the java.time APIIvan Frade2024-11-192-0/+309
| | | | | | | | | | | | | | | | | Replacement of GitDateParser that uses java.time classes instead of the obsolete Date. Updating GitDateParser would have been a mess of deprecation and methods with confusing names, so I opted for writing a parallel class with the new types. Some differences: * The new DateTimeFormatter is thread-safe, so we don't need the LocalThread cache * No code seems to use other locale than the default, we don't need to cache per locale either Change-Id: If24610a055a47702fb5b7be2fc35a7c722480ee3
* GitDateFormatterTest: Remove printlnsIvan Frade2024-05-021-2/+0
| | | | | | Left overs from https://review.gerrithub.io/c/eclipse-jgit/jgit/+/204984 Change-Id: I169ce2a008ca70267323fa4fb0f1e54981f1ec33
* Bazel: Add support for JDK 21David Ostrovsky2024-05-022-14/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two failing tests when switching to JDK 21. One failure is related to the changed behaviour related to the locale providers. Adapt `GitDateFormatterTest` to changes in unicode [1]. Second failure related to changed behaviour in URL.openConnection(), see: [2] for more details. Before JDK 20, some of the parsing/validation performed by the JDK built-in URLStreamHander implementations were delayed until URL::openConnection or URLConnection::connect was called. Starting JDK 20, some of these parsing/validations are now performed early, i.e. within URL constructors. IOW, the assumption made in HttpSupport.TesttestMalformedUri() isn't met any more: providing mailformed URI to the URL ctor now throws an exception starting with JDK 20. To rectify the problem, remove the offending test. Test plan: To build with JDK 21 and run the tests locally: $> bazel test --config=java21 //... To build with JDK 21 and run the tests on RBE: $> bazel test --config=remote21 --remote_instance_name=$PROJECT //... [1] https://bugs.openjdk.org/browse/JDK-8304925 [2] https://bugs.openjdk.org/browse/JDK-8293590 Change-Id: I796de67f7945d5f1fa5e8146f4ec8cbe9ac7bd3e
* [errorprone] Fix pattern ModifiedButNotUsedMatthias Sohn2024-04-292-0/+4
| | | | | | See https://errorprone.info/bugpattern/ModifiedButNotUsed Change-Id: I3bd3f865d50a26af6c594391de5adf35230c984f
* [errorprone] Fix pattern ProtectedMembersInFinalClassMatthias Sohn2024-04-291-1/+1
| | | | | | See https://errorprone.info/bugpattern/ProtectedMembersInFinalClass Change-Id: I5993093ca012f091dfe8ee1f2099b9596c2ee697
* [errorprone] Fix pattern CatchFailMatthias Sohn2024-04-292-3/+7
| | | | | | See https://errorprone.info/bugpattern/CatchFail Change-Id: If1c637a420c4e669a5bdbe4abcefc5c3a2b3a43b
* [errorprone] Fix pattern LongLiteralLowerCaseSuffixMatthias Sohn2024-04-291-3/+3
| | | | | | See https://errorprone.info/bugpattern/LongLiteralLowerCaseSuffix Change-Id: I139eadef5d66dfed2952ba9e1c91b3fe83259e97
* [errorprone] Fix error pattern JdkObsoleteMatthias Sohn2024-04-291-2/+2
| | | | | | See https://errorprone.info/bugpattern/JdkObsolete Change-Id: Id105e2695eb64523bd217f507bf95f909bc6b348
* FS.detectSymlinkSupport: fix a raceMotiejus Jakštys2024-02-191-0/+21
| | | | | | | | | | | When multiple JGit clients are instantiated concurrently, they may try to create the same symlink at the same time. When that happens, the second thread will return an error (because the symlink already exists) and that `FS` instance will think that symlinks are not supported, causing havoc. Change-Id: I362b933ff63a1471e3a5d70cc8c35eb2f25cc0dd Signed-off-by: Motiejus Jakštys <motiejus@jakstys.lt>
* RawParseUtils.nextLfSkippingSplitLines: fulfil contract as statedThomas Wolf2024-02-011-0/+10
| | | | | | | If there is no newline after the last header, the method is supposed to return the buffer length, but it returned buffer.length - 1. Change-Id: I9225d6a35a002244c246bc8781ceaf4369fb9a60
* RawParseUtils: utility method to get a header valueThomas Wolf2024-02-011-6/+40
| | | | | | | The new method takes care of removing the leading blanks on continuation lines in multi-line headers. Change-Id: Id5a8063512a2abc3177c104d6ba8fa50d0dc6352
* Optimize RefDirectory.getRefsByPrefix(String...)Dariusz Luksza2023-11-121-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently for file-based repositories JGit will go over all refs in the repository forach `ref-prefix` listed in the `ls-refs` command in git protocol v2 request. Native git, uses a different approach, where all refs are read once and then for each ref, all `ref-prefix` filter values are checked in one pass. This change implements this approach in JGit only in the `RefDirectory` backend. And makes `ref-prefix` filtering ~40% faster for repositories with packed refs. Different implementations were tested on a synthetic file repository with 10k refs in `refs/heads/` and `290k` in `refs/changes`. Before testing `git pack-refs` command was executed. All results are in seconds. Current Impl: 39.340 37.093 35.996 Nested for loops: 25.077 24.742 24.748 Nested streams: 24.827 24.890 27.525 Parallel stream + stream: 23.357 23.318 23.174 Nested parallel streams: 23.490 23.318 23.317 Stream + for loop: 23.147 23.210 23.126 Parallel stream + for loop: 23.317 23.423 22.847 The elapsed time was measured around `getRefByPrefix` call in `Uploadapack.getFilteredRefs(Collection<String>)` (around lines 952 and 954). For testing a modified version of `UploadPackTest.testV2LsRefsRefPrefix()` was used. The modifications here included: * shadowing protected `repo` variable with `FileRepository` pointing to the synthetic repo with 300k refs described above, * mimicking the git client clone request by adding `ref-prefix HEAD`, `ref-prefix refs/heads/` and `ref-prefix refs/tags/` Based on the above results, the implementation with parallel stream and stream was selected. Bug: 578550 Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com> Change-Id: I6416846c074b611ff6ec9d351dbafcfbcaf68e66
* WorkingTreeIterator: directly filter input streamMatthias Sohn2023-09-251-0/+152
| | | | | | | | This way we can avoid to access the byte buffers backing array. Implement a ByteBufferInputStream to wrap a byte buffer which we can use to expose the filter result as an input stream. Change-Id: I461c82090de2562ea9b649b3f953aad4571e3d25
* [errorprone] FS#searchPath: handle surprising behavior of String#splitMatthias Sohn2023-09-251-0/+23
| | | | | | See https://errorprone.info/bugpattern/StringSplitter Change-Id: Ic80f6c53ea96537ed4d046621e774288fced7ce1
* AddCommand: ability to switch off renormalizationThomas Wolf2023-04-281-10/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | JGit's AddCommand always renormalizes tracked files. C git does so only on git add --renormalize. Especially for git add . and the JGit equivalent git.add().addFilepattern(".").call() this can make a big difference if there are many files, or large files. Add a "renormalize" option to AddCommand. To maintain compatibility with existing uses, this option is "true" by default, and the behavior of AddCommand is as it has always been in JGit. If set to "false", use an IndexDiffFilter (in addition to a path filter, if any). This skips any unchanged files (that are not racily clean) from content checks. Note that changes in CRLF settings or in filters will be ignored for such files if renormalize == false. Add the "--renormalize" option to the Add command in the JGit command line program. For the command-line program, the default is as in C git: renormalize is off by default and enabled only if the option is given. Note that --renormalize implies --update in the command line program, as in C git. In AddCommand, the two settings are independent. Additionally, avoid opening input streams unnecessarily in WorkingTreeIterator.getEntryContentLength() and fix some bogus indentation. Add a simple test that adds 1000 files of 10kB in 10 directories twice and that fails if the second invocation (without any changes) with renormalize=false is not significantly faster. Locally, I observe for that second invocation * git.add().addFilepattern(".").call() ~660ms * git.add().addFilepattern(".").setRenormalize(false).call() ~16ms Bug: 494323 Change-Id: I30f9d518563fa55d7058a48c27c425f3b60aeb4c Signed-off-by: Thomas Wolf <twolf@apache.org>
* [errorprone] Fix MissingOverride errorMatthias Sohn2023-04-281-0/+1
| | | | | see https://errorprone.info/bugpattern/MissingOverride Change-Id: Iec8833eb52d91a4ef117160407b9151f25617cb5
* IntList: add #sort using quick sort for O(n log n) runtime.Anna Papitto2023-04-281-0/+34
| | | | | | | | | | | | | | IntList is a class for working with lists of primitive ints without boxing them into Integers. For writing the reverse index file format, sorting ints will be needed but IntList doesn't provide a sorting method yet. Add the #sort method to sort an IntList by an IntComparator, using quicksort, which has a average runtime of O(n log n) and sorts in-place by using O(log n) stack frames for recursive calls. Change-Id: Id69a687c8a16d46b13b28783b194a880f3f4c437 Signed-off-by: Anna Papitto <annapapitto@google.com>
* IO#readFully: provide overload that fills the full arrayAnna Papitto2022-12-191-2/+2
| | | | | | | | | | | | IO#readFully is often called with the intent to fill the destination array from beginning to end. The redundant arguments for where to start and stop filling are opportunities for bugs if specified incorrectly or if not changed to match a changed array length. Provide a overloaded method for filling the full destination array. Change-Id: I964f18f4a061189cce1ca00ff0258669277ff499 Signed-off-by: Anna Papitto <annapapitto@google.com>
* Merge branch 'stable-6.2' into stable-6.3Matthias Sohn2022-11-161-10/+59
|\ | | | | | | | | | | | | | | | | | | | | | | * stable-6.2: [benchmarks] Remove profiler configuration Add SHA1 benchmark [benchmarks] Set version of maven-compiler-plugin to 3.8.1 Fix running JMH benchmarks Add option to allow using JDK's SHA1 implementation Ignore IllegalStateException if JVM is already shutting down Change-Id: I9c1576011c11b4ff8f453d18d9e786cee59860fa
| * Merge branch 'stable-6.0' into stable-6.1Matthias Sohn2022-11-161-10/+59
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-6.0: [benchmarks] Remove profiler configuration Add SHA1 benchmark [benchmarks] Set version of maven-compiler-plugin to 3.8.1 Fix running JMH benchmarks Add option to allow using JDK's SHA1 implementation Ignore IllegalStateException if JVM is already shutting down Change-Id: I176419026c3f4fdd8ebd34c61468c1ec3482ff45
| | * Merge branch 'stable-5.13' into stable-6.0Matthias Sohn2022-11-161-10/+59
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-5.13: [benchmarks] Remove profiler configuration Add SHA1 benchmark [benchmarks] Set version of maven-compiler-plugin to 3.8.1 Fix running JMH benchmarks Add option to allow using JDK's SHA1 implementation Ignore IllegalStateException if JVM is already shutting down Change-Id: I40105336f0b9e593a8a2c242a9557f854c274fdc
| | | * Add option to allow using JDK's SHA1 implementationMatthias Sohn2022-11-151-10/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change If6da9833 moved the computation of SHA1 from the JVM's JCE to a pure Java implementation with collision detection. The extra security for public sites comes with a cost of slower SHA1 processing compared to the native implementation in the JDK. When JGit is used internally and not exposed to any traffic from external or untrusted users, the extra cost of the pure Java SHA1 implementation can be avoided, falling back to the previous native MessageDigest implementation. Bug: 580310 Change-Id: Ic24c0ba1cb0fb6282b8ca3025ffbffa84035565e
* | | | CleanCommand: fix prefix matchingThomas Wolf2022-08-031-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | String.startsWith() is not a valid test for file path prefixes: directory "a" is _not_ a prefix of a file "ab", only of "a/b". Add a proper Paths.isEqualOrPrefix() method and use it in CleanCommand. Bug: 580478 Change-Id: I6863e6ba94a8ffba6561835cc57044a0945d2770 Signed-off-by: Thomas Wolf <twolf@apache.org>
* | | | Fix DefaultCharset bug pattern flagged by error proneDavid Ostrovsky2022-06-171-14/+15
|/ / / | | | | | | | | | | | | | | | | | | See more details in: [1]. [1] https://errorprone.info/bugpattern/DefaultCharset Change-Id: I3de0be57a2d74490a5b4e66801e9767b38f13bf9
* / / [checkout] Use .gitattributes from the commit to be checked outThomas Wolf2022-03-071-1/+143
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | JGit used only one set of attributes constructed from the global and info attributes, plus the attributes from working tree, index, and HEAD. These attributes must be used to determine whether the working tree is dirty. But for actually checking out a file, one must use the attributes from global, info, and *the commit to be checked out*. Otherwise one may not pick up definitions that are only in the .gitattributes of the commit to be checked out or that are changed in that commit with respect to the attributes currently in HEAD, the index, or the working tree. Maintain in TreeWalk different Attributes per tree, and add operations to determine EOL handling and smudge filters per tree. Use the new methods in DirCacheCheckout and ResolveMerger. Note that merging in JGit actually used the attributes from the base, not those from ours, which looks dubious at least. It now uses those from ours, and for checking out the ones from theirs. The canBeContentMerged() determination was also done from the base attributes, and is newly done from the ours attributes. Possibly this should take into account all three attributes, and only if all three agree the item can be content merged, a content merge should be attempted? (What if the binary/text setting changes between base, ours, or theirs?) Also note that JGit attempts to perform content merges on non-binary LFS files; there it used the filter attribute from base, too, even for the ours and theirs versions. Newly it takes the filter attribute from the correct tree. I'm not convinced doing content merges on potentially huge files like LFS files is really a good idea. Add tests in FilterCommandsTest and LfsGitTest to verify the behavior. Open question: using index and working tree as fallback for the attributes of ours (assuming it is HEAD) is OK. But does it also make sense for base and theirs in merging? Bug: 578707 Change-Id: I0bf433e9e3eb28479b6272e17c0666e175e67d08 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* | Binary and CR-LF detection: lone CRs -> binaryThomas Wolf2021-10-312-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Factor out parsing git-style size numbers to StringUtilsThomas Wolf2021-10-301-0/+83
| | | | | | | | | | | | | | | | | | | | | | Move the code to parse numbers with an optional 'k', 'm', or 'g' suffix from the config file handling to StringUtils. This enables me to re-use it in EGit, which has duplicate code in StorageSizeFieldEditor. As this is generally useful functionality, providing it in the library makes sense. Change-Id: I86e4f5f62e14f99b35726b198ba3bbf1669418d9 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* | Make the buffer size for text/binary detection configurableThomas Wolf2021-10-302-2/+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>
* | Fix checkout of files with mixed line endings on text=auto eol=crlfThomas Wolf2021-10-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add tests for files having been checked in with mixed LF and CR-LF line endings, and then being checked out with text or text=auto and eol=lf or eol=crlf. These test cases were missing, and thus commit efd1cc05 missed that AutoCRLFOutputStream needs the same detection as AutoLFOutputStream. Fix AutoCRLFOutputStream to not convert line endings if the blob in the repository contains CR-LF. Bug: 575393 Change-Id: Id0c7ae772e282097e95fddcd3f1f9d82aae31e43 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* | Don't rely on an implicit default character setThomas Wolf2021-10-261-3/+2
|/ | | | | | | | | | | | | JEP 400 (Java 18) will change the default character set to UTF-8 unconditionally.[1] Introduce SystemReader.getDefaultCharset() that provides the locale-dependent charset the way JEP 400 recommends. Change all code locations using Charset.defaultCharset() to use the new SystemReader method instead. [1] https://openjdk.java.net/jeps/400 Change-Id: I986f97a410d2fc70748b6f93228a2d45ff100b2c Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* ApplyCommand: add a stream to apply a delta patchThomas Wolf2021-05-261-0/+103
| | | | | | | | | | | | | 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: add streams to read/write binary patch hunksThomas Wolf2021-05-261-0/+146
| | | | | | | | | | | | | Add streams that can encode or decode git binary patch data on the fly. Git writes binary patches base-85 encoded, at most 52 un-encoded bytes, with the unencoded data length prefixed in a one-character encoding, and suffixed with a newline character. Add a test for both the new input and the output stream. The test roundtrips binary data of different lengths in different ways. Bug: 371725 Change-Id: Ic3faebaa4637520f5448b3d1acd78d5aaab3907a Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* ApplyCommand: add a base-85 codecThomas Wolf2021-05-261-0/+87
| | | | | | | | | | | | | | | | | | | | | | | Add an implementation for base-85 encoding and decoding [1]. Git binary patches use this format. Base-85 encoding assembles bytes as 32-bit MSB values, then converts these values to base-85 numbers (always 5 bytes) encoded as printable ASCII characters. Decoding base-85 is the reverse operation. Note that decoding may overflow on invalid input as 85^5 > 2^32. Encodings always have a length that is a multiple of 5. If input length is not divisible by 4, padding bytes are (logically) added, which are ignored when decoding. The encoding for n bytes has thus always exactly length (n + 3) / 4 * 5 in integer arithmetic (truncating division). Includes tests. [1] https://datatracker.ietf.org/doc/html/rfc1924 Bug: 371725 Change-Id: Ib5b9a503cd62cf70e080a4fb38c8cd1eeeaebcfe Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* IO: fix IO.readFully(InputStream, byte[], int)Thomas Wolf2021-01-311-0/+84
| | | | | | | | | This would run into an endless loop if the offset given was not zero. Fix the logic to exit the read loop when the buffer is full. Luckily all existing uses of this method call it only with offset zero. Change-Id: I0ec2a4fb43efe4a605d06ac2e88cf155d50e2f1e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* TemporaryBuffer: fix toByteArray(limit)Thomas Wolf2021-01-221-0/+65
| | | | | | | Heap always copied whole blocks, which leads to AIOOBEs. LocalFile didn't overwrite the method and thus caused NPEs. Change-Id: Ia37d4a875df9f25d4825e6bc95fed7f0dff42afb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Keep line endings for text files committed with CR/LF on text=autoThomas Wolf2020-08-172-12/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* FileUtils: improve delete (Windows)Alexander Nittka2020-04-031-0/+37
| | | | | | | Ensure files are writable before trying to delete them. Bug: 408846 Change-Id: I930a547594bba853c33634ae54bd64d236afade3 Signed-off-by: Alexander Nittka <alex@nittka.de>
* Merge branch 'stable-5.6' into stable-5.7Thomas Wolf2020-04-031-0/+32
|\ | | | | | | | | | | | | | | * stable-5.6: FS.runInShell(): handle quoted filters and hooksPath containing blanks Handle non-normalized index also for executable files Change-Id: I240377e87c073ee7a621a88e39fc319c59fa037a Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
| * FS.runInShell(): handle quoted filters and hooksPath containing blanksThomas Wolf2020-04-031-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert commit 2323d7a. Using $0 in the shell command call results in the command string being taken literally. That was introduced to fix a problem with backslashes, but is actually not correct. First, the problem with backslashes occurred only on Win32/Cygwin, and has been properly fixed in commit 6f268f8. Second, this is used only for hooks (which don't have backslashes in their names) and filter commands from the git config, where the user is responsible for properly quoting or escaping such that the commands work. Third, using $0 actually breaks correctly quoted filter commands like in the bug report. The shell really takes the command literally, and then doesn't find the command because of quotes. So revert this change. At the same time there's a related problem with hooks. If the path to the hook contains blanks, runInShell() would also fail to find the hook. In this case, the command doesn't come from user input but is just a Java File object with an absolute path containing blanks. (Can occur if core.hooksPath points to such a path with blanks, or if the repository has such a path.) The path to the hook as obtained from the file system must be quoted. Add a test for a hook path with a blank. This reverts commit 2323d7a1ef909f9deb3f21329cf30bd1173ee9cf. Bug: 561666 Change-Id: I4d7df13e6c9b245fe1706e191e4316685a8a9d59 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* | Add validation to hex decoderMichael Dardis2020-03-041-0/+25
| | | | | | | | | | | | | | | | | | | | Does not fix any issue but prevents user from shooting themselves in the foot with improper configuration. Suggested by Demetr Starshov at https://git.eclipse.org/r/#/c/157681/ Change-Id: I006d65022f0a7d4066970825d00080c59404fdc3 Signed-off-by: Michael Dardis <git@md-5.net> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Merge branch 'stable-5.6'Matthias Sohn2020-02-221-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | | | * stable-5.6: Revert "Prepend hostname to subsection used to store file timestamp resolution" SimilarityRenameDetector: Fix inconsistent indentation Use indexOf(char) and lastIndexOf(char) rather than String versions Reorder modifiers to follow Java Language Specification GitmoduleEntry: Remove redundant import of class from same package Remove redundant "static" qualifier from enum declarations Change-Id: Ibb66bef7e8373f81e3e653c9843d986243446d68 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * Reorder modifiers to follow Java Language SpecificationDavid Pursehouse2020-02-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Java Language Specification recommends listing modifiers in the following order: 1. Annotations 2. public 3. protected 4. private 5. abstract 6. static 7. final 8. transient 9. volatile 10. synchronized 11. native 12. strictfp Not following this convention has no technical impact, but will reduce the code's readability because most developers are used to the standard order. This was detected using SonarLint. Change-Id: I9cddecb4f4234dae1021b677e915be23d349a380 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* | Remove use of org.bouncycastle.util.encoders.HexMichael Dardis2020-02-221-0/+49
| | | | | | | | | | Change-Id: I5c1ed0397ef99eb5d4f120da331b66c2d0f1707a Signed-off-by: Michael Dardis <git@md-5.net> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Remove use of org.bouncycastle.util.io.TeeOutputStreamMichael Dardis2020-02-211-0/+81
| | | | | | | | | | | | Bug: 559106 Change-Id: Ife06f21a00d258780a2030745738194098c631cf Signed-off-by: Michael Dardis <git@md-5.net> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Removed unused importsAndrey Loskutov2020-02-171-1/+0
| | | | | | | | | | | | | | | | This fixes compilation errors in 4.15 M3 Bug: 560210 Change-Id: I7f36edc7fb83c66c8889d7573b4439d5a52334e4 Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* | ErrorProne: Enable and fix UnusedException checkDavid Pursehouse2020-01-271-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable UnusedException at ERROR level which causes the build to fail in many places with: [UnusedException] This catch block catches an symbol and re-throws another, but swallows the caught symbol rather than setting it as a cause. This can make debugging harder. Fix it by setting the caught exception as cause on the subsequently thrown exception. Note: The grammatically incorrect error message is copy-pasted as-is from the version of ErrorProne currently used in Bazel; it has been fixed by [1] in the latest version. [1] https://github.com/google/error-prone/commit/d57a39c Change-Id: I11ed38243091fc12f64f1b2db404ba3f1d2e98b5 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-09 03:30:05 +0000