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
$ 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