Community
Participate
Working Groups
We use jgit via gerrit and git archive command seems do not read .git attributes from remote repository before compressing and sending it Gerrit version: 2.16.6 What steps will reproduce the problem? 1. ~/tmp/AppShell3 % git archive --format=tar.gz --remote=ssh://gerrit-server:29418/Repo1 V_BRANCH1 | tar zxf - Bring all files with eol LF 2./tmp/AppShell4 % git archive --format=tar.gz --remote=git@gerrit-server:/git/Repo1 V_BRANCH1 | tar zxf - Regular git archive via ssh port 22 not related to gerrit, works as expected, brings *.mht file eol CRLF windows style 3. this is the repository Repo1.gitattributes file # Declare files that will always have CRLF line endings on checkout. *.mht eol=crlf What is the expected output? To see *.mht files in CRLF eol By default git archive reads .gitattributes before compressing and sending archive
Yes. See org.eclipse.jgit.archive.TarFormat.putEntry(): this just copies the blob, ignoring any CR/LF conversions or other attributes.[1] It also doesn't implement the export-ignore and export-subst attributes. Smudge filters probably might not work. Unclear to me how canonical git would handle that... The same problem also exists in ZipFormat.[2] [1] https://git.eclipse.org/r/plugins/gitiles/jgit/jgit/+/master/org.eclipse.jgit.archive/src/org/eclipse/jgit/archive/TarFormat.java#138 [2] https://git.eclipse.org/r/plugins/gitiles/jgit/jgit/+/master/org.eclipse.jgit.archive/src/org/eclipse/jgit/archive/ZipFormat.java#122
(In reply to Thomas Wolf from comment #1) > Smudge filters probably might not work. Unclear to me how canonical git > would handle that... To clarify: might in particular not work with --remote. The smudge filter might refer to an executable not available on the server.
