[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Don't use $author_name undefined when $from contains no /\s<
Re: [PATCH] Don't use $author_name undefined when $from contains no /\s</.
Thu, 19 Oct 2006 20:16:02 +0200
Junio C Hamano <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>> I noticed a case not handled in a recent patch.
> Thanks. Will apply.
> Curiously your patch was whitespace damaged.
I wondered what you meant, so compared what I sent
with the output of the command I ran:
git-format-patch --stdout --signoff HEAD~1
There were two differences, both involving removed trailing blanks.
The first was a part of the diff: a line consisting of a single space
denoting an empty line in the context. I understood that those types
of lines may safely be truncated (removing the trailing blank),
and in fact, GNU diff -u (cvs) now does this by default:
2006-09-05 Paul Eggert <address@hidden>
* NEWS: diff -u no longer outputs trailing white space unless the
input data has it. Suggested by Jim Meyering.
* doc/diff.texi (Detailed Unified): Document this.
* src/context.c (pr_unidiff_hunk): Implement this.
The only other difference was the removal of the trailing blank following
the "--" signature introducer.
I see that git-apply does not handle this new format:
$ git-apply patch
fatal: corrupt patch at line 47
That diagnostic comes from builtin-apply.c:
if (len <= 0)
die("corrupt patch at line %d", linenr);
It would be nice if git would accept such unified diff output,
since no other program we know of rejects them. Paul Eggert has
even submitted revised wording to make POSIX allow this style
For reference, the GNU diff thread started here:
- Re: [PATCH] Don't use $author_name undefined when $from contains no /\s</.,
Jim Meyering <=