Ok, it seems that i have forgotten one rev, so patch -p1 < test.patch work for the the first rev now.
If i try "git am" i got the message: error: appc/dbc/functions.inc.php: does not exist in index error: tests/bootstrap.php: does not exist in index What is "better"? git am or patch ? On 5 Aug., 13:57, Konstantin Khomoutov <flatw...@users.sourceforge.net> wrote: > On Fri, 5 Aug 2011 04:07:32 -0700 (PDT) > > > > Thorsten Peters <impyna...@googlemail.com> wrote: > > i have some problems with git patches. > > > I have a SVN Trunk and a GIT Trunk. > > Now i want to add svn changes to git. > > > I do: > > git svn clone svnTrunk svnTrunkClone > > git log --oneline > > git format-patch 1b5b9e7..f58e5d6 > > > patch -p 1 < name.patch > > (git apply doesnt work) > > > Errors from git apply: > > error: patch failed: standard/tests/cases/de/dbcentral/standard/login/ > > LoginRouteStandardTest.php:20 > > error: standard/tests/cases/de/dbcentral/standard/login/ > > LoginRouteStandardTest.php: patch does not apply > > > Error from path > > patching file tests/cases/de/dbcentral/standard/login/ > > LoginRouteStandardTest.php > > Hunk #1 FAILED at 20. > > 1 out of 1 hunk FAILED -- saving rejects to file tests/cases/de/ > > dbcentral/standard/login/LoginRouteStandardTest.php.rej > > These errors actually look the same: same hunk of the same file failed > at the same line. > > > Any ideas? > > Some possible cases to investigate: > > First, git-format-patch formats a patch *series* for e-mail submission. > This means when you run it with $rev1...$rev2, it prepares *several* > patches--one for each revision; if you use "--stdout", it generates one > stream of patches, but they're still distinct. > In either case, this program produces something suitable for `git am`, > that is, it produces a "Unix-style mailbox file". Hence you could try > to run `git am` on the generated file(s). > > And this leads us to a second thought: to create a patch representing > the changeset introduced by one particular commit or a range of commits, > you could just do > $ git show $rev >that_rev.patch > or > $ git show $rev1..$rev2 >another.patch > But note than in the latter case the patches will be in "reverse > order", that is, in the order `git log` would show the commits given > the same revision spec. > > Last, Git patches are no different from the "standard" unidiff format > produced by `diff -u ...` (and understood by `patch`), except that > Git also includes some meta information about added or deleted files > and their (POSIX) filesystem access permission bits. I'm not sure, but > this could leave the `patch` utility puzzled. > Your errors do not look like being induced by this bit, though. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
