motiejus
/
jgit
1
Fork 0
Code Releases Activity
jgit/org.eclipse.jgit/.settings/.api_filters

238 lines
9.9 KiB
Plaintext
Raw Normal View History

Honor CRLF settings when writing merge results Merges are performed using the raw text as stored in the git repository. When we write the merge result, we must apply the correct CRLF settings. Otherwise the line endings in the result will be wrong. Bug: 499615 Change-Id: I37a9b987e9404c97645d2720cd1c7c04c076a96b Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-02-01 22:58:23 +02:00
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<component id="org.eclipse.jgit" version="2">
Add missing @since tag and silence API error These methods were introduced for 4.11.1 so we have to silence the API error adding API in a service release raises. Change-Id: Ic847cebbed439912d3979ec2ec1809f77a28f61e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-03-27 01:35:40 +03:00
<resource path="META-INF/MANIFEST.MF">
Silence API warning for new ObjectIdSerializer introduced in 4.11.1 Change-Id: Ic271dae300f7554b7e13bb1f44006e5b38c00011 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-08-24 19:33:50 +03:00
<filter id="924844039">
Declare ConfigConstants and GitProtocolConstants final This avoids that we have to suppress API errors whenever we add a new constant in a minor release. This change affects implementors only which is ok to do in a minor release following OSGi semantic versioning rules. Change-Id: Iece841886fbe00f1ba567c5ff68093c542ba265e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-08-15 01:31:37 +03:00
<message_arguments>
Fix API problem filters Change-Id: I0f7a72934022346c9903d7dc5ec11e959cc8dac3 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-06-17 01:34:49 +03:00
<message_argument value="5.1.9"/>
Merge branch 'stable-5.0' into stable-5.1 * stable-5.0: Fix atomic lock file creation on NFS Use constant for ".lock" Fix handling of option core.supportsAtomicCreateNewFile GC: Avoid logging errors when deleting non-empty folders Change-Id: I3c8892e33516bdcadd983e7ab668635b7fa3d4c5 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-09-08 12:17:38 +03:00
<message_argument value="5.1.0"/>
LFS: support merge/rebase/cherry-pick/diff/compare with LFS files Respect merge=lfs and diff=lfs attributes where required to replace (in memory) the content of LFS pointers with the actual blob content from the LFS storage (and vice versa when staging/merging). Does not implement general support for merge/diff attributes for any other use case apart from LFS. Change-Id: Ibad8875de1e0bee8fe3a1dffb1add93111534cae Signed-off-by: Markus Duft <markus.duft@ssi-schaefer.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-03-02 11:11:42 +02:00
</message_arguments>
</filter>
Declare ConfigConstants and GitProtocolConstants final This avoids that we have to suppress API errors whenever we add a new constant in a minor release. This change affects implementors only which is ok to do in a minor release following OSGi semantic versioning rules. Change-Id: Iece841886fbe00f1ba567c5ff68093c542ba265e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-08-15 01:31:37 +03:00
</resource>
Use Instant instead of milliseconds for filesystem timestamp handling This enables higher file timestamp resolution on filesystems like ext4, Mac APFS (1ns) or NTFS (100ns) providing high timestamp resolution on filesystem level. Note: - on some OSes Java 8,9 truncate milliseconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes truncates timestamp resolution to microseconds when converting the internal representation to FileTime exposed in the API, see https://bugs.openjdk.java.net/browse/JDK-8181493 - WindowsFileAttributes also provides only microsecond resolution Change-Id: I25ffff31a3c6f725fc345d4ddc2f26da3b88f6f2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-07-03 02:07:14 +03:00
<resource path="src/org/eclipse/jgit/dircache/DirCacheEntry.java" type="org.eclipse.jgit.dircache.DirCacheEntry">
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="getLastModifiedInstant()"/>
</message_arguments>
</filter>
Use Instant for smudge time in DirCache and DirCacheEntry Change-Id: I98050a51baf4726c5717ef62ce7f026173666bdf Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-07-18 04:36:18 +03:00
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="mightBeRacilyClean(Instant)"/>
</message_arguments>
</filter>
Use Instant instead of milliseconds for filesystem timestamp handling This enables higher file timestamp resolution on filesystems like ext4, Mac APFS (1ns) or NTFS (100ns) providing high timestamp resolution on filesystem level. Note: - on some OSes Java 8,9 truncate milliseconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes truncates timestamp resolution to microseconds when converting the internal representation to FileTime exposed in the API, see https://bugs.openjdk.java.net/browse/JDK-8181493 - WindowsFileAttributes also provides only microsecond resolution Change-Id: I25ffff31a3c6f725fc345d4ddc2f26da3b88f6f2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-07-03 02:07:14 +03:00
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="setLastModified(Instant)"/>
</message_arguments>
</filter>
</resource>
Remember the cause for invalidating a packfile Keep track of the original cause for a packfile invalidation. It is needed for the sysadmin to understand if there is a real underlying filesystem problem and repository corruption or if it is simply a consequence of a concurrency of Git operations (e.g. repack or GC). Change-Id: I06ddda9ec847844ec31616ab6d17f153a5a34e33 Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com> Signed-off-by: David Pursehouse <david.pursehouse@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-04-09 12:44:06 +03:00
<resource path="src/org/eclipse/jgit/errors/PackInvalidException.java" type="org.eclipse.jgit.errors.PackInvalidException">
<filter id="1142947843">
<message_arguments>
<message_argument value="4.5.7"/>
<message_argument value="PackInvalidException(File, Throwable)"/>
</message_arguments>
</filter>
<filter id="1142947843">
<message_arguments>
<message_argument value="4.5.7"/>
<message_argument value="PackInvalidException(String, Throwable)"/>
</message_arguments>
</filter>
</resource>
Persist filesystem timestamp resolution and allow manual configuration To enable persisting filesystem timestamp resolution per FileStore add a new config section to the user global git configuration: - Config section is "filesystem" - Config subsection is concatenation of - Java vendor (system property "java.vm.vendor") - runtime version (system property "java.vm.version") - FileStore's name - separated by '|' e.g. "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1" The prefix is needed since some Java versions do not expose the full timestamp resolution of the underlying filesystem. This may also depend on the underlying operating system hence concrete key values may not be portable. - Config key for timestamp resolution is "timestampResolution" as a time value, supported time units are those supported by DefaultTypedConfigGetter#getTimeUnit If timestamp resolution is already configured for a given FileStore the configured value is used instead of measuring the resolution. When timestamp resolution was measured it is persisted in the user global git configuration. Example: [filesystem "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1"] timestampResolution = 1 seconds If locking the git config file fails retry saving the resolution up to 5 times in order to workaround races with another thread. In order to avoid stack overflow use the fallback filesystem timestamp resolution when loading FileBasedConfig which creates itself a FileSnapshot to help checking if the config changed. Note: - on some OSes Java 8,9 truncate to milliseconds or seconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes up to Java 12 truncates timestamp resolution to microseconds when converting the internal representation to FileTime exposed in the API, see https://bugs.openjdk.java.net/browse/JDK-8181493 - WindowsFileAttributes also provides only microsecond resolution up to Java 12 Hence do not attempt to manually configure a higher timestamp resolution than supported by the Java version being used at runtime. Bug: 546891 Bug: 548188 Change-Id: Iff91b8f9e6e5e2295e1463f87c8e95edf4abbcf8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-06-21 19:12:14 +03:00
<resource path="src/org/eclipse/jgit/lib/ConfigConstants.java" type="org.eclipse.jgit.lib.ConfigConstants">
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="CONFIG_FILESYSTEM_SECTION"/>
</message_arguments>
</filter>
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="CONFIG_KEY_TIMESTAMP_RESOLUTION"/>
</message_arguments>
</filter>
</resource>
<resource path="src/org/eclipse/jgit/lib/Constants.java" type="org.eclipse.jgit.lib.Constants">
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="FALLBACK_TIMESTAMP_RESOLUTION"/>
</message_arguments>
</filter>
</resource>
ObjectChecker: Report .gitmodules files found in the pack In order to validate .gitmodules files, we first need to find them in the incoming pack. Do it in the ObjectChecker stage. Check in the tree objects if they point to a .gitmodules file and report the tree id and the .gitmodules blob id. This can be used later to check if the file is in the root of the project and if the contents are good. While we're here, make isMacHFSGit more accurate by detecting variants of filenames that vary in case. [jn: tweaked NTFS and HFS+ checking; added more tests] Change-Id: I70802e7d2c1374116149de4f89836b9498f39582 Signed-off-by: Ivan Frade <ifrade@google.com> Signed-off-by: Jonathan Nieder <jrn@google.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-09-27 23:05:13 +03:00
<resource path="src/org/eclipse/jgit/lib/GitmoduleEntry.java" type="org.eclipse.jgit.lib.GitmoduleEntry">
<filter id="1109393411">
Declare ConfigConstants and GitProtocolConstants final This avoids that we have to suppress API errors whenever we add a new constant in a minor release. This change affects implementors only which is ok to do in a minor release following OSGi semantic versioning rules. Change-Id: Iece841886fbe00f1ba567c5ff68093c542ba265e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-08-15 01:31:37 +03:00
<message_arguments>
ObjectChecker: Report .gitmodules files found in the pack In order to validate .gitmodules files, we first need to find them in the incoming pack. Do it in the ObjectChecker stage. Check in the tree objects if they point to a .gitmodules file and report the tree id and the .gitmodules blob id. This can be used later to check if the file is in the root of the project and if the contents are good. While we're here, make isMacHFSGit more accurate by detecting variants of filenames that vary in case. [jn: tweaked NTFS and HFS+ checking; added more tests] Change-Id: I70802e7d2c1374116149de4f89836b9498f39582 Signed-off-by: Ivan Frade <ifrade@google.com> Signed-off-by: Jonathan Nieder <jrn@google.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-09-27 23:05:13 +03:00
<message_argument value="4.7.5"/>
<message_argument value="org.eclipse.jgit.lib.GitmoduleEntry"/>
Declare ConfigConstants and GitProtocolConstants final This avoids that we have to suppress API errors whenever we add a new constant in a minor release. This change affects implementors only which is ok to do in a minor release following OSGi semantic versioning rules. Change-Id: Iece841886fbe00f1ba567c5ff68093c542ba265e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-08-15 01:31:37 +03:00
</message_arguments>
</filter>
</resource>
ObjectChecker: Report .gitmodules files found in the pack In order to validate .gitmodules files, we first need to find them in the incoming pack. Do it in the ObjectChecker stage. Check in the tree objects if they point to a .gitmodules file and report the tree id and the .gitmodules blob id. This can be used later to check if the file is in the root of the project and if the contents are good. While we're here, make isMacHFSGit more accurate by detecting variants of filenames that vary in case. [jn: tweaked NTFS and HFS+ checking; added more tests] Change-Id: I70802e7d2c1374116149de4f89836b9498f39582 Signed-off-by: Ivan Frade <ifrade@google.com> Signed-off-by: Jonathan Nieder <jrn@google.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-09-27 23:05:13 +03:00
<resource path="src/org/eclipse/jgit/lib/ObjectChecker.java" type="org.eclipse.jgit.lib.ObjectChecker">
<filter id="1142947843">
Silence API errors raised for new public fields in PackStatistics Change-Id: I8e118282a833361b676aa3cc90cbe774ccd42ed0 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-02-18 23:08:39 +02:00
<message_arguments>
ObjectChecker: Report .gitmodules files found in the pack In order to validate .gitmodules files, we first need to find them in the incoming pack. Do it in the ObjectChecker stage. Check in the tree objects if they point to a .gitmodules file and report the tree id and the .gitmodules blob id. This can be used later to check if the file is in the root of the project and if the contents are good. While we're here, make isMacHFSGit more accurate by detecting variants of filenames that vary in case. [jn: tweaked NTFS and HFS+ checking; added more tests] Change-Id: I70802e7d2c1374116149de4f89836b9498f39582 Signed-off-by: Ivan Frade <ifrade@google.com> Signed-off-by: Jonathan Nieder <jrn@google.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-09-27 23:05:13 +03:00
<message_argument value="4.7.5"/>
<message_argument value="getGitsubmodules()"/>
Silence API errors raised for new public fields in PackStatistics Change-Id: I8e118282a833361b676aa3cc90cbe774ccd42ed0 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-02-18 23:08:39 +02:00
</message_arguments>
</filter>
</resource>
Wait opening new packfile until it can't be racy anymore If - pack.waitPreventRacyPack = true (default is false) - packfile size > pack.minSizePreventRacyPack (default is 100 MB) wait after a new packfile was written and before it is opened until it cannot be racy anymore. If a new packfile is accessed while it's still racy at least the pack's index will be reread by ObjectDirectory.scanPacksImpl(). Hence it may save resources to wait one tick of the file system timer to avoid this reloading. On filesystems with a coarse timestamp resolution it may be beneficial to skip this wait for small packfiles. Bug: 546891 Change-Id: I0e8bf3d7677a025edd2e397dd2c9134ba59b1a18 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-05-09 02:23:15 +03:00
<resource path="src/org/eclipse/jgit/storage/pack/PackConfig.java" type="org.eclipse.jgit.storage.pack.PackConfig">
<filter id="336658481">
<message_arguments>
<message_argument value="org.eclipse.jgit.storage.pack.PackConfig"/>
<message_argument value="DEFAULT_MINSIZE_PREVENT_RACY_PACK"/>
</message_arguments>
</filter>
<filter id="336658481">
<message_arguments>
<message_argument value="org.eclipse.jgit.storage.pack.PackConfig"/>
<message_argument value="DEFAULT_WAIT_PREVENT_RACY_PACK"/>
</message_arguments>
</filter>
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.8"/>
<message_argument value="DEFAULT_MINSIZE_PREVENT_RACY_PACK"/>
</message_arguments>
</filter>
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.8"/>
<message_argument value="DEFAULT_WAIT_PREVENT_RACY_PACK"/>
</message_arguments>
</filter>
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.8"/>
<message_argument value="doWaitPreventRacyPack(long)"/>
</message_arguments>
</filter>
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.8"/>
<message_argument value="getMinSizePreventRacyPack()"/>
</message_arguments>
</filter>
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.8"/>
<message_argument value="isWaitPreventRacyPack()"/>
</message_arguments>
</filter>
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.8"/>
<message_argument value="setMinSizePreventRacyPack(long)"/>
</message_arguments>
</filter>
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.8"/>
<message_argument value="setWaitPreventRacyPack(boolean)"/>
</message_arguments>
</filter>
</resource>
JGit v5.1.4.201812251853-r Change-Id: I30ba167bcd8144074553d7446a45fa6be19584fe Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-12-26 01:42:14 +02:00
<resource path="src/org/eclipse/jgit/transport/TransferConfig.java" type="org.eclipse.jgit.transport.TransferConfig">
<filter id="1159725059">
<message_arguments>
<message_argument value="5.1.4"/>
<message_argument value="TransferConfig(Config)"/>
</message_arguments>
</filter>
<filter id="1159725059">
<message_arguments>
<message_argument value="5.1.4"/>
<message_argument value="TransferConfig(Repository)"/>
</message_arguments>
</filter>
</resource>
Use Instant instead of milliseconds for filesystem timestamp handling This enables higher file timestamp resolution on filesystems like ext4, Mac APFS (1ns) or NTFS (100ns) providing high timestamp resolution on filesystem level. Note: - on some OSes Java 8,9 truncate milliseconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes truncates timestamp resolution to microseconds when converting the internal representation to FileTime exposed in the API, see https://bugs.openjdk.java.net/browse/JDK-8181493 - WindowsFileAttributes also provides only microsecond resolution Change-Id: I25ffff31a3c6f725fc345d4ddc2f26da3b88f6f2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-07-03 02:07:14 +03:00
<resource path="src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java" type="org.eclipse.jgit.treewalk.WorkingTreeIterator">
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="getEntryLastModifiedInstant()"/>
</message_arguments>
</filter>
</resource>
<resource path="src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java" type="org.eclipse.jgit.treewalk.WorkingTreeIterator$Entry">
<filter id="336695337">
<message_arguments>
<message_argument value="org.eclipse.jgit.treewalk.WorkingTreeIterator.Entry"/>
<message_argument value="getLastModifiedInstant()"/>
</message_arguments>
</filter>
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="getLastModifiedInstant()"/>
</message_arguments>
</filter>
</resource>
Merge branch 'stable-5.0' into stable-5.1 * stable-5.0: Prepare 4.11.8-SNAPSHOT builds JGit v4.11.7.201903122105-r Prepare 4.9.10-SNAPSHOT builds JGit v4.9.9.201903122025-r Prepare 4.7.9-SNAPSHOT builds JGit v4.7.8.201903121755-r Prepare 4.5.7-SNAPSHOT builds JGit v4.5.6.201903121547-r Check for packfile validity and fd before reading Move throw of PackInvalidException outside the catch Use FileSnapshot to get lastModified on PackFile Include size when comparing FileSnapshot Do not reuse packfiles when changed on filesystem Silence API warnings for new API introduced for fixes Change-Id: I71771dcc086a9a0097bad74d65ec71ad97106a38 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-03-13 08:37:36 +02:00
<resource path="src/org/eclipse/jgit/util/FS.java" type="org.eclipse.jgit.util.FS">
<filter id="1142947843">
Silence API errors raised for new public fields in PackStatistics Change-Id: I8e118282a833361b676aa3cc90cbe774ccd42ed0 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-02-18 23:08:39 +02:00
<message_arguments>
Merge branch 'stable-5.0' into stable-5.1 * stable-5.0: Prepare 4.11.8-SNAPSHOT builds JGit v4.11.7.201903122105-r Prepare 4.9.10-SNAPSHOT builds JGit v4.9.9.201903122025-r Prepare 4.7.9-SNAPSHOT builds JGit v4.7.8.201903121755-r Prepare 4.5.7-SNAPSHOT builds JGit v4.5.6.201903121547-r Check for packfile validity and fd before reading Move throw of PackInvalidException outside the catch Use FileSnapshot to get lastModified on PackFile Include size when comparing FileSnapshot Do not reuse packfiles when changed on filesystem Silence API warnings for new API introduced for fixes Change-Id: I71771dcc086a9a0097bad74d65ec71ad97106a38 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-03-13 08:37:36 +02:00
<message_argument value="4.5.6"/>
<message_argument value="fileAttributes(File)"/>
Silence API errors raised for new public fields in PackStatistics Change-Id: I8e118282a833361b676aa3cc90cbe774ccd42ed0 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-02-18 23:08:39 +02:00
</message_arguments>
</filter>
Use Instant instead of milliseconds for filesystem timestamp handling This enables higher file timestamp resolution on filesystems like ext4, Mac APFS (1ns) or NTFS (100ns) providing high timestamp resolution on filesystem level. Note: - on some OSes Java 8,9 truncate milliseconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes truncates timestamp resolution to microseconds when converting the internal representation to FileTime exposed in the API, see https://bugs.openjdk.java.net/browse/JDK-8181493 - WindowsFileAttributes also provides only microsecond resolution Change-Id: I25ffff31a3c6f725fc345d4ddc2f26da3b88f6f2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-07-03 02:07:14 +03:00
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="lastModifiedInstant(File)"/>
</message_arguments>
</filter>
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="lastModifiedInstant(Path)"/>
</message_arguments>
</filter>
Optionally measure filesystem timestamp resolution asynchronously In order to avoid blocking on the main thread during measurement interactive applications like EGit may want to measure the filesystem timestamp resolution asynchronously. In order to enable measurement in the background call FileStoreAttributeCache.setAsyncfileStoreAttrCache(true) before the first access to cached FileStore attributes. Bug: 548188 Change-Id: I8c9a2dbfc3f1d33441edea18b90e36b1dc0156c7 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-06-21 14:37:32 +03:00
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="setAsyncfileStoreAttrCache(boolean)"/>
</message_arguments>
</filter>
Use Instant instead of milliseconds for filesystem timestamp handling This enables higher file timestamp resolution on filesystems like ext4, Mac APFS (1ns) or NTFS (100ns) providing high timestamp resolution on filesystem level. Note: - on some OSes Java 8,9 truncate milliseconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes truncates timestamp resolution to microseconds when converting the internal representation to FileTime exposed in the API, see https://bugs.openjdk.java.net/browse/JDK-8181493 - WindowsFileAttributes also provides only microsecond resolution Change-Id: I25ffff31a3c6f725fc345d4ddc2f26da3b88f6f2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-07-03 02:07:14 +03:00
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="setLastModified(Path, Instant)"/>
</message_arguments>
</filter>
Measure file timestamp resolution used in FileSnapshot FileSnapshot.notRacyClean() assumed a worst case filesystem timestamp resolution of 2.5 sec (FAT has a resolution of 2 sec). Instead measure timestamp resolution to avoid unnecessary IO caused by false positives in detecting the racy git problem caused by finite filesystem timestamp resolution [1]. Cache the measured resolution per FileStore since timestamp resolution depends on the respective filesystem type. If timestamp resolution cannot be measured or fails due to an exception fallback to the worst case FAT timestamp resolution and avoid caching this value. Add a 10% safety margin in FileSnapshot.notRacyClean(), though running FsTest.testFsTimestampResolution() 1000 times which is not using a safety margin didn't fail on Mac using APFS and Java 8, 11, 12. Measured Java file timestamp resolution: [2] [1] https://github.com/git/git/blob/master/Documentation/technical/racy-git.txt [2] https://docs.google.com/spreadsheets/d/1imy0y6WmRqBf0kjCxzxj2X7M50eIVfa7oaUIzEOHmjo Bug: 546891 Change-Id: I493f3b57b6b306285ffa7d392339d253e5966ab8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-05-05 04:18:23 +03:00
<filter id="1142947843">
<message_arguments>
<message_argument value="5.2.3"/>
<message_argument value="getFsTimerResolution(Path)"/>
</message_arguments>
</filter>
</resource>
Use Instant instead of milliseconds for filesystem timestamp handling This enables higher file timestamp resolution on filesystems like ext4, Mac APFS (1ns) or NTFS (100ns) providing high timestamp resolution on filesystem level. Note: - on some OSes Java 8,9 truncate milliseconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes truncates timestamp resolution to microseconds when converting the internal representation to FileTime exposed in the API, see https://bugs.openjdk.java.net/browse/JDK-8181493 - WindowsFileAttributes also provides only microsecond resolution Change-Id: I25ffff31a3c6f725fc345d4ddc2f26da3b88f6f2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-07-03 02:07:14 +03:00
<resource path="src/org/eclipse/jgit/util/FS.java" type="org.eclipse.jgit.util.FS$Attributes">
<filter id="1142947843">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="getLastModifiedInstant()"/>
</message_arguments>
</filter>
</resource>
Measure file timestamp resolution used in FileSnapshot FileSnapshot.notRacyClean() assumed a worst case filesystem timestamp resolution of 2.5 sec (FAT has a resolution of 2 sec). Instead measure timestamp resolution to avoid unnecessary IO caused by false positives in detecting the racy git problem caused by finite filesystem timestamp resolution [1]. Cache the measured resolution per FileStore since timestamp resolution depends on the respective filesystem type. If timestamp resolution cannot be measured or fails due to an exception fallback to the worst case FAT timestamp resolution and avoid caching this value. Add a 10% safety margin in FileSnapshot.notRacyClean(), though running FsTest.testFsTimestampResolution() 1000 times which is not using a safety margin didn't fail on Mac using APFS and Java 8, 11, 12. Measured Java file timestamp resolution: [2] [1] https://github.com/git/git/blob/master/Documentation/technical/racy-git.txt [2] https://docs.google.com/spreadsheets/d/1imy0y6WmRqBf0kjCxzxj2X7M50eIVfa7oaUIzEOHmjo Bug: 546891 Change-Id: I493f3b57b6b306285ffa7d392339d253e5966ab8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-05-05 04:18:23 +03:00
<resource path="src/org/eclipse/jgit/util/FileUtils.java" type="org.eclipse.jgit.util.FileUtils">
<filter id="1142947843">
<message_arguments>
Use FileChannel.open to touch file and set mtime to now Use options - StandardOpenOption.CREATE to create touched file if not existing - StandardOpenOption.SYNC to enforce synch of data and meta data changes - StandardOpenOption.WRITE Also set mtime explicitly in FileUtils#touch to the current system time. This should fix that the previous implementation didn't work on - locally cached Windows network share (CSC-CACHE filesystem) mapped as a drive - nfsv4 mounts on Linux and that it didn't create unborn file like Linux command "touch". Apache common's and Guava's touch() use the same approach. Immediately after creating the probe file used to measure timestamp resolution touch it. This ensures we always use the local system clock when measuring filesystem timestamp resolution. This should prevent that clock skew could influence the measured timestamp resolution in case of a mounted network filesystem. Bug: 548598 Change-Id: Iaeaf5967963f582395a195aa637b8188bfadac60 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-06-26 02:11:12 +03:00
<message_argument value="5.1.8"/>
Measure file timestamp resolution used in FileSnapshot FileSnapshot.notRacyClean() assumed a worst case filesystem timestamp resolution of 2.5 sec (FAT has a resolution of 2 sec). Instead measure timestamp resolution to avoid unnecessary IO caused by false positives in detecting the racy git problem caused by finite filesystem timestamp resolution [1]. Cache the measured resolution per FileStore since timestamp resolution depends on the respective filesystem type. If timestamp resolution cannot be measured or fails due to an exception fallback to the worst case FAT timestamp resolution and avoid caching this value. Add a 10% safety margin in FileSnapshot.notRacyClean(), though running FsTest.testFsTimestampResolution() 1000 times which is not using a safety margin didn't fail on Mac using APFS and Java 8, 11, 12. Measured Java file timestamp resolution: [2] [1] https://github.com/git/git/blob/master/Documentation/technical/racy-git.txt [2] https://docs.google.com/spreadsheets/d/1imy0y6WmRqBf0kjCxzxj2X7M50eIVfa7oaUIzEOHmjo Bug: 546891 Change-Id: I493f3b57b6b306285ffa7d392339d253e5966ab8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-05-05 04:18:23 +03:00
<message_argument value="touch(Path)"/>
</message_arguments>
</filter>
Silence API errors raised for new public fields in PackStatistics Change-Id: I8e118282a833361b676aa3cc90cbe774ccd42ed0 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-02-18 23:08:39 +02:00
</resource>
Add test for racy git detection in FileSnapshot Repeat the test 10000 times to get statistics if measured fsTimestampResolution is working in practice to detect racy git situations. Add a class to compute statistics for this test. Log delta between lastModified and time when FileSnapshot failed to detect modification. This happens if the racy git limit determined by measuring filesystem timestamp resolution and clock resolution is too small. If it would be correct FileSnapshot would always detect modification or mark it modified if time since modification is smaller than the racy git limit. Change-Id: Iabe7af1a7211ca58480f8902d4fa4e366932fc77 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-07-12 10:49:13 +03:00
<resource path="src/org/eclipse/jgit/util/Stats.java" type="org.eclipse.jgit.util.Stats">
<filter id="1109393411">
<message_arguments>
<message_argument value="5.1.9"/>
<message_argument value="org.eclipse.jgit.util.Stats"/>
</message_arguments>
</filter>
</resource>
Honor CRLF settings when writing merge results Merges are performed using the raw text as stored in the git repository. When we write the merge result, we must apply the correct CRLF settings. Otherwise the line endings in the result will be wrong. Bug: 499615 Change-Id: I37a9b987e9404c97645d2720cd1c7c04c076a96b Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-02-01 22:58:23 +02:00
</component>