author | Jonathan Nieder <jrnieder@gmail.com> | |
Thu, 19 Aug 2010 01:50:14 +0000 (20:50 -0500) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Sun, 22 Aug 2010 06:04:29 +0000 (23:04 -0700) | ||
commit | 5a12c8864b9485351547a45fc759dde30dd1d870 | |
tree | 541cc5a79d07ecb514347e9571dba7f89d533036 | tree | snapshot |
parent | c51c0da2225d65ec1984d40bacbc3f43a0bfa178 | commit | diff |
apply: handle traditional patches with space in filename
To discover filenames from the --- and +++ lines in a traditional
unified diff, currently "git apply" scans forward for a whitespace
character on each line and stops there. It can't use the whole line
because "diff -u" likes to include timestamps, like so:
--- foo 2000-07-12 16:56:50.020000414 -0500
+++ bar 2010-07-12 16:56:50.020000414 -0500
The whitespace-seeking heuristic works great, even when the tab
has been converted to spaces by some email + copy-and-paste
related corruption.
Except for one problem: if the filename itself contains whitespace,
the inferred filename will be too short.
When Giuseppe ran into this problem, it was for a file creation
patch (for debian/licenses/LICENSE.global BSD-style Chromium).
So one can't use the list of files present in the index to deduce an
appropriate filename (not to mention that way lies madness; see
v0.99~402, 2005-05-31).
Instead, look for a timestamp and use that if present to mark the end
of the filename. If no timestamp is present, the old heuristic is
used, with one exception: the space character \040 is not considered
terminating whitespace any more unless it is followed by a timestamp.
Reported-by: Giuseppe Iuculano <iuculano@debian.org>
Acked-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To discover filenames from the --- and +++ lines in a traditional
unified diff, currently "git apply" scans forward for a whitespace
character on each line and stops there. It can't use the whole line
because "diff -u" likes to include timestamps, like so:
--- foo 2000-07-12 16:56:50.020000414 -0500
+++ bar 2010-07-12 16:56:50.020000414 -0500
The whitespace-seeking heuristic works great, even when the tab
has been converted to spaces by some email + copy-and-paste
related corruption.
Except for one problem: if the filename itself contains whitespace,
the inferred filename will be too short.
When Giuseppe ran into this problem, it was for a file creation
patch (for debian/licenses/LICENSE.global BSD-style Chromium).
So one can't use the list of files present in the index to deduce an
appropriate filename (not to mention that way lies madness; see
v0.99~402, 2005-05-31).
Instead, look for a timestamp and use that if present to mark the end
of the filename. If no timestamp is present, the old heuristic is
used, with one exception: the space character \040 is not considered
terminating whitespace any more unless it is followed by a timestamp.
Reported-by: Giuseppe Iuculano <iuculano@debian.org>
Acked-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/apply.c | diff | blob | history | |
t/t4135-apply-weird-filenames.sh | diff | blob | history |