missing handling of "No newline at end of file" in git am

How is git send-email and git am supposed to handle a text file which lacks a newline at the very end? This is about git 2.11.0.

Right now the patch in an email generated with 'git send-email' ends with '\ No newline at end of file', which 'git am' can not handle. To me it looks like whatever variant of "diff" is used does the right thing and indicates the lack of newline. Just the used variant of "patch" does not deal with it.

Olaf

Olaf Hering <olaf@aepfle.de> writes:

I think this has always worked, though.

    $ cd /var/tmp/x
    $ git init am-incomplete-line
    $ cd am-incomplete-line/
    $ echo one line >file
    $ git add file
    $ git commit -a -m initial
    [master (root-commit) 27b4668] initial
     1 file changed, 1 insertion(+)
     create mode 100644 file
    $ echo -n an incomplete line >>file
    $ git diff file
    diff --git a/file b/file
    index e3c0674..f2ec9f0 100644
    --- a/file
    +++ b/file
    @@ -1 +1,2 @@
     one line
    +an incomplete line
    \ No newline at end of file
    $ git commit -a -m 'incomplete second'
    [master 57075ab] incomplete second
     1 file changed, 1 insertion(+)
    $ git format-patch -1
    0001-incomplete-second.txt
    $ cat 0001-incomplete-second.txt
    From 57075ab402e2d3714ebc9e2e9d4efd8dbfd74d5a Mon Sep 17 00:00:00 2001
    From: Junio C Hamano <gitster@pobox.com>
    Date: Tue, 14 Feb 2017 12:35:50 -0800
    Subject: [PATCH] incomplete second

    ---
     file | 1 +
     1 file changed, 1 insertion(+)

    diff --git a/file b/file
    index e3c0674..f2ec9f0 100644
    --- a/file
    +++ b/file
    @@ -1 +1,2 @@
     one line
    +an incomplete line
    \ No newline at end of file
    -- 
    2.12.0-rc1-235-g2fb706ef99
    $ git checkout HEAD^
    $ git am ./0001-incomplete-second.txt
    Applying: incomplete second
    $ git diff master
    $ exit

Am Tue, 14 Feb 2017 12:40:36 -0800 schrieb Junio C Hamano <gitster@pobox.com>:

For me it complains in line 721, which is the problematic one. I try to apply from mutt via (cd /some/dir && git am), but that probably does not make a difference.

How would I debug it?

Olaf

On Tue, Feb 14, Olaf Hering wrote:

One line is supposed to be longer than 998 chars, but something along the way truncated it and corrupted the patch. No idea why the error today is different from the error yesterday. 'git pull' has to be used in this case.

Olaf

Olaf Hering <olaf@aepfle.de> wrote:

998 sounds like the SMTP limit.

Perhaps git format-patch should emit binary diffs in that case? I doubt any human would bother reading excessively long lines as text...

On Tue, Feb 14, 2017 at 09:11:04PM +0100, Olaf Hering wrote:

That workflow should handle this case, and the resulting applied patch should not have a newline.

I can't reproduce here:

  # new repo with nothing in it (the base commit is to have something to
  # reset back to)
  git init
  git commit --allow-empty -m base

  # our file with no trailing newline
  printf foo >file
  git add file
  git commit -m no-newline

  # now make a patch email; it should have the "\ No newline" bit at the
  # end.
  git format-patch -1
  cat 0001-no-newline.patch

  # and now reset back and try to apply it
  git reset --hard HEAD^
  git am 0001-no-newline.patch

  # double check that it has no newline
  xxd <file

I'm using format-patch instead of send-email, but that is the underlying command that send-email is using. Is it possible that your patch is getting munged during email transit in a way that destroy the "No newline" message?

-Peff