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

79 lines
3.9 KiB
Plaintext
Raw Normal View History

Fix @since tag for introduction of PUBKEY_ACCEPTED_ALGORITHMS This constant was shipped with 5.11.1. Change-Id: I480dbefab1cccca78cefbc709b79e5405f8bf8cd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2021-05-14 10:02:46 +03:00
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<component id="org.eclipse.jgit" version="2">
Merge branch 'stable-5.13' into stable-6.0 * stable-5.13: Stop initCause throwing in readAdvertisedRefs Change-Id: I94251601aa7fae9cc65164eaddcf16471874b11e
2022-02-09 01:32:10 +02:00
<resource path="src/org/eclipse/jgit/errors/NoRemoteRepositoryException.java" type="org.eclipse.jgit.errors.NoRemoteRepositoryException">
<filter id="1141899266">
searchForReuse might impact performance in large repositories The search for reuse phase for *all* the objects scans *all* the packfiles, looking for the best candidate to serve back to the client. This can lead to an expensive operation when the number of packfiles and objects is high. Add parameter "pack.searchForReuseTimeout" to limit the time spent on this search. Change-Id: I54f5cddb6796fdc93ad9585c2ab4b44854fa6c48
2021-06-03 17:15:17 +03:00
<message_arguments>
Merge branch 'stable-5.13' into stable-6.0 * stable-5.13: Stop initCause throwing in readAdvertisedRefs Change-Id: I94251601aa7fae9cc65164eaddcf16471874b11e
2022-02-09 01:32:10 +02:00
<message_argument value="5.13"/>
Merge branch 'stable-6.0' * stable-6.0: Stop initCause throwing in readAdvertisedRefs Change-Id: I2266814c613fd81e9dfc722532ac3daa30ca66b5
2022-02-09 01:47:49 +02:00
<message_argument value="6.1"/>
Merge branch 'stable-5.13' into stable-6.0 * stable-5.13: Stop initCause throwing in readAdvertisedRefs Change-Id: I94251601aa7fae9cc65164eaddcf16471874b11e
2022-02-09 01:32:10 +02:00
<message_argument value="NoRemoteRepositoryException(URIish, String, Throwable)"/>
Fix @since tag for introduction of PUBKEY_ACCEPTED_ALGORITHMS This constant was shipped with 5.11.1. Change-Id: I480dbefab1cccca78cefbc709b79e5405f8bf8cd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2021-05-14 10:02:46 +03:00
</message_arguments>
</filter>
</resource>
Add a typed config getter for integers confined to a range Use Integer#MIN_VALUE to denote unset option. Change-Id: I4d65f2434013111f25520c0ed2b9a9dc8123c6cf
2022-02-22 02:20:07 +02:00
<resource path="src/org/eclipse/jgit/lib/TypedConfigGetter.java" type="org.eclipse.jgit.lib.TypedConfigGetter">
<filter id="403767336">
<message_arguments>
<message_argument value="org.eclipse.jgit.lib.TypedConfigGetter"/>
<message_argument value="UNSET_INT"/>
</message_arguments>
</filter>
<filter id="403804204">
<message_arguments>
<message_argument value="org.eclipse.jgit.lib.TypedConfigGetter"/>
Describe: add support for core.abbrev config option If core.abbrev is unset or "auto" estimate abbreviation length like C git does: - Estimate repository's object count by only considering packed objects, round up to next power of 2 - With the order of 2^len objects, we expect a collision at 2^(len/2). But we also care about hex chars, not bits, and there are 4 bits per hex. So all together we need to divide by 2; but we also want to round odd numbers up, hence adding one before dividing. - For small repos use at least 7 hexdigits - If object database fails to determine object count use 7 hexdigits as fallback If it is set to "no" do not abbreviate object-ids. Otherwise set it to the configured value capped to the range between 4 and length of an unabbreviated object-id. Change-Id: I425f9724b69813dbb57872466bf2d2e1d6dc72c6
2022-02-21 03:29:27 +02:00
<message_argument value="getIntInRange(Config, String, String, String, int, int, int)"/>
</message_arguments>
</filter>
</resource>
<resource path="src/org/eclipse/jgit/lib/ObjectDatabase.java" type="org.eclipse.jgit.lib.ObjectDatabase">
<filter id="336695337">
<message_arguments>
<message_argument value="org.eclipse.jgit.lib.ObjectDatabase"/>
<message_argument value="getApproximateObjectCount()"/>
</message_arguments>
</filter>
</resource>
<resource path="src/org/eclipse/jgit/lib/TypedConfigGetter.java" type="org.eclipse.jgit.lib.TypedConfigGetter">
<filter id="403804204">
<message_arguments>
<message_argument value="org.eclipse.jgit.lib.TypedConfigGetter"/>
Add a typed config getter for integers confined to a range Use Integer#MIN_VALUE to denote unset option. Change-Id: I4d65f2434013111f25520c0ed2b9a9dc8123c6cf
2022-02-22 02:20:07 +02:00
<message_argument value="getIntInRange(Config, String, String, String, int, int, int)"/>
</message_arguments>
</filter>
</resource>
[checkout] Use .gitattributes from the commit to be checked out 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>
2022-02-14 00:30:36 +02:00
<resource path="src/org/eclipse/jgit/merge/ResolveMerger.java" type="org.eclipse.jgit.merge.ResolveMerger">
<filter id="338792546">
<message_arguments>
<message_argument value="org.eclipse.jgit.merge.ResolveMerger"/>
<message_argument value="addCheckoutMetadata(String, Attributes)"/>
</message_arguments>
</filter>
<filter id="338792546">
<message_arguments>
<message_argument value="org.eclipse.jgit.merge.ResolveMerger"/>
<message_argument value="addToCheckout(String, DirCacheEntry, Attributes)"/>
</message_arguments>
</filter>
<filter id="338792546">
<message_arguments>
<message_argument value="org.eclipse.jgit.merge.ResolveMerger"/>
<message_argument value="processEntry(CanonicalTreeParser, CanonicalTreeParser, CanonicalTreeParser, DirCacheBuildIterator, WorkingTreeIterator, boolean, Attributes)"/>
</message_arguments>
</filter>
</resource>
Merge branch 'stable-6.0' * stable-6.0: Stop initCause throwing in readAdvertisedRefs Change-Id: I2266814c613fd81e9dfc722532ac3daa30ca66b5
2022-02-09 01:47:49 +02:00
<resource path="src/org/eclipse/jgit/transport/BasePackPushConnection.java" type="org.eclipse.jgit.transport.BasePackPushConnection">
<filter id="338792546">
<message_arguments>
<message_argument value="org.eclipse.jgit.transport.BasePackPushConnection"/>
<message_argument value="noRepository()"/>
</message_arguments>
</filter>
</resource>
Support for git config push.default Enhance the (unused!?) PushConfig; include a PushDefault enumeration. Add simple tests for this PushConfig. Bug: 351314 Change-Id: Ibc5656a2a1fccf70d00c5e15de8ed3dd8add6337 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2022-02-09 19:33:31 +02:00
<resource path="src/org/eclipse/jgit/transport/PushConfig.java" type="org.eclipse.jgit.transport.PushConfig">
<filter id="338722907">
<message_arguments>
<message_argument value="org.eclipse.jgit.transport.PushConfig"/>
<message_argument value="PushConfig()"/>
</message_arguments>
</filter>
</resource>
Fix @since tag for introduction of PUBKEY_ACCEPTED_ALGORITHMS This constant was shipped with 5.11.1. Change-Id: I480dbefab1cccca78cefbc709b79e5405f8bf8cd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2021-05-14 10:02:46 +03:00
</component>