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.

Reply via email to