aitor_czr <aitor_czr@???> writes:
> On 12/20/2015 01:02 PM, aitor_czr wrote:
>>>> On 12/19/2015 05:52 PM, Edward Bartolo<edbarx@???> wrote:
>>>>>> >> >The command:
>>>>>> >> >edbarx@edbarx-pc:~/netman_from_backup_08.12.2015$ git patch
>>>>>> >> >../rainer_dng-15.12.2015.patch
>>>> >
>>>> >The right command is this other one:
>>>> >
>>>> >$ git apply --stat ../rainer_dng-15.12.2015.patch
>>> Hi Aitor,
>>>
>>> Thanks for your reply. Git is reporting that the patch is corrupted. I
>>> informed Rainer about that.
>>>
>>> Edward
>>
>> Rainer's patch is not corrupted:
>>

>> $ git apply --stat ../rainer_dng-15.12.2015.patch
>>  Makefile                      |   10 +++++++++-
>>  debian/netman-backend.install |    2 +-
>>  debian/rules                  |    9 ---------
>>  3 files changed, 10 insertions(+), 11 deletions(-)

>
> My bad :)
>
> The above command doen't change nothing. I aplplied the patch by the
> following way (in the parent directory):
>
> $ patch < rainer_dng-15.12.2015.patch
> can't find file to patch at input line 5
> Perhaps you should have used the -p or --strip option?

Patches are (as I already wrote in the past) commonly generated
such that the top-level directory has to be stripped away by patch (as
this means people can use different names for 'top-level directories',
ie,

patch -p1 <../patch

assuming the patch file resides above the top-level directory.

Further, as I also already wrote, the text in the first mail I sent had
the tabs in the Makefile changes expanded to spaces. This means while
the patch itself isn't corrupted (as a patch), it will end up corrupting
the Makefiles by replacing the leading tabs with spaces.