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 
For more options, visit this group at 

Reply via email to