Git Patch fails to apply with Svn Patch

2014-05-01 Thread Eric Berge
I was running "svn patch" with a patch I created with "git diff" and it
failed to apply, however it applies just fine with the default "patch"
command on my Rhel 6.5 system.

This is due to the "extended header" information that git puts before the
actual diff in some cases.  I validated this by removing the lines
beginning with "old mode" and "new mode" in the patch below (file "PATCH2")
and then "svn patch" applied the patch successfully.

I'd like to request that "svn patch" be able to ignore this extended header
information and be able to apply the patch successfully without getting the
"skipping missing target" error.  I guess there's an argument that some of
this extended header info should be processed by "svn patch" but for, for
my purposes, it would be enough that it ignored it and applied the rest of
the patch.

Here's an example (in this case the extended header is describing a chmod
change to the target file, indicated by the "old mode" and "new mode"
lines):



*$ cat PATCH2*
*diff --git a/Makefile b/Makefile*
*old mode 100644*
*new mode 100755*
*index caef0a5..310e8e9*
*--- a/Makefile*
*+++ b/Makefile*
*@@ -5,6 +5,7 @@ export BUILD_SYS_ROOT*
* export BUILD_TARGET_ROOT*
* export BUILD_DIR*
* export CMAKE_PASSTHROUGH_ARGS*
*+export ADD_FAKE_VARIABLE*
* export DESTDIR*
* export DISTPKG_LOC*
* export WITH_MOVER*
*$ svn patch PATCH2*
*Skipped missing target: 'b/Makefile'*
*Summary of conflicts:*
*  Skipped paths: 1*
*$ patch -p1 < PATCH2*
*patching file Makefile*
*$ svn diff*
*Index: Makefile*
*===*
*--- Makefile (revision 42326)*
*+++ Makefile (working copy)*
*@@ -5,6 +5,7 @@*
* export BUILD_TARGET_ROOT*
* export BUILD_DIR*
* export CMAKE_PASSTHROUGH_ARGS*
*+export ADD_FAKE_VARIABLE*
* export DESTDIR*
* export DISTPKG_LOC*
* export WITH_MOVER*



Thanks for your consideration of this request,

Eric Berge
Senior File System Developer, StorNext File System
Quantum Corporation
eric.be...@quantum.com



P.S.  Just for your reference, if you're curious about what the full set of
"extended header" info git generates, the following is from the git-diff
man page from the version (1.8.2.1) running on my system:

   old mode 
   new mode 
   deleted file mode 
   new file mode 
   copy from 
   copy to 
   rename from 
   rename to 
   similarity index 
   dissimilarity index 
   index .. 


Re: Git Patch fails to apply with Svn Patch

2014-05-02 Thread Eric Berge
The original patch file I used is attached.

Thanks!

Eric



On Fri, May 2, 2014 at 4:05 AM, Stefan Sperling  wrote:

> On Thu, May 01, 2014 at 02:30:33PM -0500, Eric Berge wrote:
> > I was running "svn patch" with a patch I created with "git diff" and it
> > failed to apply, however it applies just fine with the default "patch"
> > command on my Rhel 6.5 system.
> >
> > This is due to the "extended header" information that git puts before the
> > actual diff in some cases.  I validated this by removing the lines
> > beginning with "old mode" and "new mode" in the patch below (file
> "PATCH2")
> > and then "svn patch" applied the patch successfully.
>
> Hi Eric,
>
> can you please re-send the patch which failed to apply as an attachment?
> It seem your mailer mangled the patch. The patch format is whitespace
> sensitive, unfortunately (e.g. tabs vs. spaces matter).
>
> Thanks!
>


PATCH2
Description: Binary data


Re: Git Patch fails to apply with Svn Patch

2014-05-02 Thread Eric Berge
That sounds right to me, thanks Stefan!

Eric


On Fri, May 2, 2014 at 2:50 PM, Stefan Sperling  wrote:

> On Fri, May 02, 2014 at 02:06:46PM -0500, Eric Berge wrote:
> > The original patch file I used is attached.
> >
> > Thanks!
> >
> > Eric
> >
>
> Thanks, I could reproduce the problem and fix it.
> See http://svn.apache.org/r1592014
> I've nominated the fix for backport to 1.8.x so it should appear
> in some future 1.8.x release.
>
> Regarding your suggestion about an option switch to disable --git diff
> parsing: I think we should rather fix the parser to accept and ignore
> unknown git diff headers (as I've just done) instead of requiring the
> user to pass a command line option to work around a broken parser.
>
> Thanks for your bug report!
>