Hi, > > apply using the standard unix "patch -p1" (to get rid of the crazy a/b path > prefix, also not existent in the SVN diffs). After that I must take care to > not > forget to add files, adjust svn props because only stock "svn patch" command > can do this for me. > > Don't want to go into flame wars, but I think it's svn patch that's crippled > here, not git's. A git patch is pretty standard (?). It also contains file > additions/ > removal (via /dev/null referencing), unlike svn's (may be wrong here -- I'm > not up to date with svn's recent progress). Sure, svn properties are not > supported but hey -- they're, ehm, svn properties.
>From the point of view of a "patch" in the unix world, both approaches are >correct - in general "a" and "b" looks strange to me and unintuitive. The use >of /dev/null or not does not matter, as UNIX patch is documented to work with >both. My comment was not meant for flamewars, it is just the additional work I have to do and that it is more error prone and sometimes makes it impossible to apply older GIT patches. The technology is fine, I just have problems with the usability. If I work on an issue and there is a large non-SVN patch applied and it is older than 3 days I don't even try anymore to apply the patch. There is one more useful feature of svn patch for windows users: It uses svn:eol-stlye to normalize the line endings in the patch with locally used ones. If I apply the patch with UNIX(Cygwin) patch (without dos2unix or unix2dos), my files suddenly have mixed line endings and then SVN heavily complains on committing. This drives me crazy... In that case I simply stop working on the issue and ask the use to resubmit a subversion conform patch (same with non-unified diffs). One more thing: If we intend to start testing patches from JIRA with Jenkins (as Grant proposed, the JIRA plugin for this was implemented by some Hadoop people, as far as I remember), we need the SVN metadata to cleanly apply patches in heavy-committing times. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
