mirrors/jgit - jgit - source @ dussan.org

8343 Commits

49 Branches

Tree: 7a925205db

Commit Graph

Author	SHA1	Message	Date
Thomas Wolf	d2846cc8b2	ApplyCommand: convert to git internal format before applying patch Applying a patch on Windows failed if the patch had the (normal) single-LF line endings, but the file on disk had the usual Windows CR-LF line endings. Git (and JGit) compute diffs on the git-internal blob, i.e., after CR-LF transformation and clean filtering. Applying patches to files directly is thus incorrect and may fail if CR-LF settings don't match, or if clean/smudge filtering is involved. Change ApplyCommand to run the file content through the check-in filters before applying the patch, and run the result through the check-out filters. This makes patch application succeed even if the patch has single-LFs, but the file has CR-LF and core.autocrlf is true. Add tests for various combinations of line endings in the file and in the patch, and a test to verify the clean/smudge handling. See also [1]. Running the file though clean/smudge may give strange results with LFS-managed files. JGit's DiffFormatter has some extra code and applies the smudge filter again after having run the file through the check-in filters (CR-LF and clean). So JGit can actually produce a diff on LFS-managed files using the normal diff machinery. (If it doesn't run out of memory, that is. After all, LFS is intended for _large_ files.) How such a diff would be applied with either C git or JGit is entirely unclear; neither has any code for this special case. Compare also [2]. Note that C git just doesn't know about LFS and always diffs after the check-in filter chain, so for LFS files, it'll produce a diff of the LFS pointers. [1] https://github.com/git/git/commit/c24f3abac [2] https://github.com/git-lfs/git-lfs/issues/440 Bug: 571585 Change-Id: I8f71ff26313b5773ff1da612b0938ad2f18751f5 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>	3 years ago

Author

SHA1

Message

Date

Thomas Wolf

d2846cc8b2

ApplyCommand: convert to git internal format before applying patch

Applying a patch on Windows failed if the patch had the (normal)
single-LF line endings, but the file on disk had the usual Windows
CR-LF line endings.

Git (and JGit) compute diffs on the git-internal blob, i.e., after
CR-LF transformation and clean filtering. Applying patches to files
directly is thus incorrect and may fail if CR-LF settings don't
match, or if clean/smudge filtering is involved.

Change ApplyCommand to run the file content through the check-in
filters before applying the patch, and run the result through the
check-out filters. This makes patch application succeed even if the
patch has single-LFs, but the file has CR-LF and core.autocrlf is
true.

Add tests for various combinations of line endings in the file and in
the patch, and a test to verify the clean/smudge handling.

See also [1].

Running the file though clean/smudge may give strange results with
LFS-managed files. JGit's DiffFormatter has some extra code and
applies the smudge filter again after having run the file through
the check-in filters (CR-LF and clean). So JGit can actually produce
a diff on LFS-managed files using the normal diff machinery. (If it
doesn't run out of memory, that is. After all, LFS is intended for
_large_ files.) How such a diff would be applied with either C git
or JGit is entirely unclear; neither has any code for this special
case. Compare also [2].

Note that C git just doesn't know about LFS and always diffs after
the check-in filter chain, so for LFS files, it'll produce a diff
of the LFS pointers.

[1] https://github.com/git/git/commit/c24f3abac
[2] https://github.com/git-lfs/git-lfs/issues/440

Bug: 571585
Change-Id: I8f71ff26313b5773ff1da612b0938ad2f18751f5
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

3 years ago

1 Commits (7a925205dbcd3863d73ea9fa17c4253e2f01f9ff)