[REGRESSION] git-archive stores files with CRLF

[orgads]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.24.0.windows.2
cpu: x86_64
built from commit: 02af2cc5bfc37d4500e8a09333269e57f442198a
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.18362.418]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled
Enable Builtin Interactive Add: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

core.autocrlf=true

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git archive -o foo.tar.gz HEAD

• What did you expect to occur after running these commands?

I expect it to have unconverted LF line-endings.

• What actually happened instead?

It depends on core.autocrlf. If core.autocrlf is true then the archive is stored with CRLF. Otherwise, it has only LF.

This breaks the use-case of deploying a tarball from a Windows machine to Linux which is sensitive to CRLF line endings.

It used to work correctly, but I'm not sure exactly on which version it broke. I can try to bisect if needed.

[tboegi]

The "Minimal, Complete, and Verifiable example" is not verifiable,
since we don't know how HEAD is constructed, right ?

[orgads]

Never mind. I now see that this is the expected behavior, according to t0024-crlf-archive.sh. So maybe it always had CRLF, and I just didn't use shell scripts and such on linux.

Sorry for the noise.

[tboegi]

It seems that the expected behavior is debatable ;-)
See the history of t0024:

commit f1265cc
Author: Charles Bailey [email protected]
Date: Thu Sep 18 21:01:13 2008 +0100

Add new test to demonstrate git archive core.autocrlf inconsistency

[orgads]

The inconsistency was that tar had CRLF and zip had LF.

I'll just suggest the colleague that complained about it to use git -c core.autocrlf=false archive.

[tboegi]

Just for the record:
object_file_to_archive() in archive.c
calls
convert_to_working_tree(args->repo->index, path, buf.buf, buf.len, &buf);
(So that is by design)
And the documentation says
"git-archive - Create an archive of files from a named tree"

Which zip file are you referring to?

[orgads]

git archive can create tar or zip, according to --format or the file extension. See git@b99b5b4 for the zip fix.