Sverre Rabbelier <srabbel...@gmail.com> writes:
> I noticed something very odd with git am, and have been able to narrow
> it down to a minimal example.
> git init tmp
> cd tmp
> mkdir -p foo/bar/baz
> cd foo/bar/baz
> echo file > file
> git add file
> git commit -m "1"
> echo other > other
> echo more >> file
> git add file other
> git commit -m "my test"
> git format-patch HEAD~..
> git reset --hard HEAD~
> # apply the patch in the current directory, chop off the leading directories
> git am -3 -p 3 0001-my-test.patch
> cd ../../..
> git ls-files
> Expected output:
> Actual output:
> baz/other # the file addition was applied to the root of the
> repository, instead of the current directory
> foo/bar/baz/file # the file modification was correctly applied, yay
> Is this expected behavior?
As you are doing -3 (not the -p3), it would have:
* noticed that the patch is trying to update "baz/file";
* noticed that there is no "baz/file" but it could salvage the
patch by doing a three-way merge, in case that the patch was
prepared against a tree that moved path "foo/bar/baz" to "baz";
* such a three-way merge succeeds cleanly for a path whose movement
was detected correctly.
So it does not look odd at all to me (the use of "-p 3" does look
odd, but I know this is an effort to come up with a minimum example,
so it is understandable that it may look contribed ;-).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html