git am oddity

git am oddity

[Sverre Rabbelier]

Hi,

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:
foo/bar/baz/file
foo/bar/baz/other

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?

-- 
Cheers,

Sverre Rabbelier

Re: git am oddity

[Junio C Hamano]

Sverre Rabbelier <srabbelier@gmail.com> writes:

> Hi,
>
> 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:
> foo/bar/baz/file
> foo/bar/baz/other
>
> 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";
   and

 * 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 ;-).

Re: git am oddity

[Sverre Rabbelier]

On Mon, Mar 31, 2014 at 3:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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";
>    and
>
>  * 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 ;-).

Ah, we were thinking that 'git am' (when run from a subdirectory),
would apply the patches "from the current directory". So the right
solution was to instead do:

$  git am --directory=foo/bar/baz -p 3 0001-my-test.patch

Thank you,

-- 
Cheers,

Sverre Rabbelier