summaryrefslogtreecommitdiff
path: root/t/t5515/fetch.br-remote-glob-octopus_remote-glob
diff options
context:
space:
mode:
authorLibravatar Paolo Bonzini <pbonzini@redhat.com>2014-11-25 15:00:27 +0100
committerLibravatar Junio C Hamano <gitster@pobox.com>2014-11-25 14:00:15 -0800
commit8d8140843501107c92e2f9a5acb60ee136352c1f (patch)
tree2eda57e5aa49f7ecc457e0385538e7b2258e88cf /t/t5515/fetch.br-remote-glob-octopus_remote-glob
parentgit-send-email: delay creation of MIME headers (diff)
downloadtgif-8d8140843501107c92e2f9a5acb60ee136352c1f.tar.xz
git-send-email: add --transfer-encoding option
The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t5515/fetch.br-remote-glob-octopus_remote-glob')
0 files changed, 0 insertions, 0 deletions