Skip to main content
aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorThomas Wolf2022-02-13 22:30:36 +0000
committerMatthias Sohn2022-03-07 17:45:25 +0000
commitf26ab4ebee52b6a595859690087a276658ea425b (patch)
treecd19fb03c3e54f8e54f1c3fa13b02ae7c5019c89 /org.eclipse.jgit/.settings/.api_filters
parent72bba7bd53389407037ef63a14bab6aa5e6bc3ef (diff)
downloadjgit-f26ab4ebee52b6a595859690087a276658ea425b.tar.gz
jgit-f26ab4ebee52b6a595859690087a276658ea425b.tar.xz
jgit-f26ab4ebee52b6a595859690087a276658ea425b.zip
[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>
Diffstat (limited to 'org.eclipse.jgit/.settings/.api_filters')
-rw-r--r--org.eclipse.jgit/.settings/.api_filters20
1 files changed, 20 insertions, 0 deletions
diff --git a/org.eclipse.jgit/.settings/.api_filters b/org.eclipse.jgit/.settings/.api_filters
index e026e31dc5..00b89a4b3d 100644
--- a/org.eclipse.jgit/.settings/.api_filters
+++ b/org.eclipse.jgit/.settings/.api_filters
@@ -39,6 +39,26 @@
</message_arguments>
</filter>
</resource>
+ <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>
<resource path="src/org/eclipse/jgit/transport/BasePackPushConnection.java" type="org.eclipse.jgit.transport.BasePackPushConnection">
<filter id="338792546">
<message_arguments>

Back to the top