diff options
| author | Thomas Wolf <thomas.wolf@paranor.ch> | 2018-11-20 12:24:38 +0100 |
|---|---|---|
| committer | Matthias Sohn <matthias.sohn@sap.com> | 2018-11-26 00:30:21 +0100 |
| commit | f974c9c790dc383b425e9f0ef047251e79354bb7 (patch) | |
| tree | 3a8ef03c51507a49f50eb959709663ec759d2a93 /org.eclipse.jgit.http.apache/src/org | |
| parent | 6f68ed2ed392f87959b7473fecf32a4844d484b8 (diff) | |
| download | jgit-f974c9c790dc383b425e9f0ef047251e79354bb7.tar.gz jgit-f974c9c790dc383b425e9f0ef047251e79354bb7.zip | |
Undo treating blobs with NULs as a single line
This partially reverts commit a551b646: revert the changes in
RawParseUtils.lineMap(). Forcing all blobs containing a NUL byte
as a single line causes blame to produce useless results as soon
as it hits any version containing a NUL byte.
Doing binary detection at this level also has the problem that the
user cannot control it. Not by setting the text attribute nor in any
other way.
This came up in bug 541036, where a Java source inadvertently
contained NUL bytes in strings. Even fixing this by using escapes
"\000" will not fix JGit's blame for this file because the past
versions will still contain the NUL byte.
Native git can blame that file from bug 541036 fine.
Added new tests verifying that blaming a text file containing a NUL
byte produces sensible results.
Bug: 541036
Change-Id: I8991bec88e9827cc096868c6026ea1890b6d0d32
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Diffstat (limited to 'org.eclipse.jgit.http.apache/src/org')
0 files changed, 0 insertions, 0 deletions