[
https://issues.apache.org/jira/browse/OOZIE-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323110#comment-15323110
]
Peter Cseh commented on OOZIE-2532:
-----------------------------------
The patch files in OOZIE-2445 are incorrect. They may have been generated from
a different base, or a first commit was missed from them.
A patch with a new file looks like this:
{noformat}
diff --git a/core/distcp-log4j.properties b/core/distcp-log4j.properties
new file mode 100644
index 0000000..ec4348b
--- /dev/null
+++ b/core/distcp-log4j.properties
@@ -0,0 +1,61 @@
...
{noformat}
The patch in OOZIE-2445 looks like this:
{noformat}
diff --git examples/src/main/apps/coord-input-logic/workflow.xml
examples/src/main/apps/coord-input-logic/workflow.xml
index
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..80d31457eff6e78710ad1fb4d4f1b372c0d1e43c
100644
--- examples/src/main/apps/coord-input-logic/workflow.xml
+++ examples/src/main/apps/coord-input-logic/workflow.xml
@@ -0,0 +1,61 @@
{noformat}
This means that there was an empty file named workflow.xml in that folder and
it got 61 lines inserted into it.
The empty file is not there so git apply fails.
> patch apply does not handle binary files
> ----------------------------------------
>
> Key: OOZIE-2532
> URL: https://issues.apache.org/jira/browse/OOZIE-2532
> Project: Oozie
> Issue Type: Task
> Reporter: Peter Cseh
> Assignee: Peter Cseh
> Fix For: trunk
>
> Attachments: OOZIE-2532-001.patch, OOZIE-2532-002.patch
>
>
> In OOZIE-2482 there is a patch which contains binary files as well.
> After running
> {quote}patch -E -p0 <~/Downloads/OOZIE-2482-2.patch {quote}
> the folder sharelib/spark/src/test/resources contains only pi.py, and not the
> zip files.
> {quote}git apply -p0 <~/Downloads/OOZIE-2482-2.patch {quote}
> processes the binary part of the patch as well.
> Git documentation claims that patches created with --binary can be applied
> with git apply, I assume they know that it's not compatible with the patch
> command.
> Should we change this in the Jenkins job or we should keep this behavior as a
> gatekeeper to prevent binary files committed to master?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
