`ab | (cd cd && git apply -)' fails with v2.0.0

Hello (again, psssssst, after a long time),

it happened yesterday that i needed to do

  $ git diff HEAD:FILE COMMIT:SAME-FILE |
  > (cd src && git apply -) 

but found that didn't work with v2.0.0 (silently succeeds?, doing nothing). It works without the subshell and the cd(1); i had to use `(cd src && patch -p2)' instead to keep in going. Just in case that is not known yet (i've updated my git(1) repo, but in the 1466 commits in between nothing sprung into my eye regarding apply, and a Gmane search didn't, too). No need to Cc: me, please just fix it; thank you. Ciao,

--steffen

Steffen Nurpmeso venit, vidit, dixit 24.07.2014 15:29:

Ah little more context would help. Are you diffing files in the subdir src, or a file at the root which happens to be present in the subdir src as well?

Michael

Michael J Gruber <git@drmicha.warpmail.net> writes:

As the <treeish>:<path> form is not meant to produce "git apply" applicable patch in the first place, I am not sure what the OP is trying to achieve in the first place. Not just "how many leading levels to strip?" but "which file is being modified?" does not appear in a usable form. For example, here is what you would see:

    $ git diff HEAD:GIT-VERSION-GEN maint:GIT-VERSION-GEN
    diff --git a/HEAD:GIT-VERSION-GEN b/maint:GIT-VERSION-GEN
    index 40adbf7..0d1a86c 100755
    --- a/HEAD:GIT-VERSION-GEN
    +++ b/maint:GIT-VERSION-GEN
    @@ -1,7 +1,7 @@
    ...

and neither "HEAD:GIT-VERSION-GEN" nor "maint:GIT-VERSION-GEN" is the file being modified ("GIT-VERSION-GEN" is).

I would understand if the upstream of the pipe were

    $ git diff HEAD maint -- GIT-VERSION-GEN | ...

though.

Needless to say, if the place "cd" goes is not a worktree controlled by git, then "git apply" would not know where the top-level of the target tree is, so even though the input with the corrected command on the upstream side of the pipe tells it which file is being modified, it needs to be told with the proper -p<n> parameter how many leading levels to strip.

Junio C Hamano venit, vidit, dixit 24.07.2014 19:19:

I thought "git apply" knows how to strip the rev part.

I think it's a common mistake to think of "git apply" as some sort of magic extension of "patch" which can do anything that "patch" does and more, and can be fed anything that "git diff" produces", figuring out by itself what to do with it :)

Michael

Hello and good morning,

Michael J Gruber <git@drmicha.warpmail.net> wrote:
 |Junio C Hamano venit, vidit, dixit 24.07.2014 19:19:
 |> Michael J Gruber <git@drmicha.warpmail.net> writes:
 |>> Steffen Nurpmeso venit, vidit, dixit 24.07.2014 15:29:
 |>>> Hello (again, psssssst, after a long time),
 |>>>
 |>>> it happened yesterday that i needed to do
 |>>>
 |>>>   $ git diff HEAD:FILE COMMIT:SAME-FILE |
 |>>>> (cd src && git apply -) 
 |>>> ...
 |>>
 |>> Ah little more context would help. Are you diffing files in the subdir
 |>> src, or a file at the root which happens to be present in the subdir src
 |>> as well?
 |> 
 |> As the <treeish>:<path> form is not meant to produce "git apply"
 |> applicable patch in the first place, I am not sure what the OP is
 |> trying to achieve in the first place.  Not just "how many leading
 |> levels to strip?" but "which file is being modified?" does not
 |> appear in a usable form.  For example, here is what you would see:
 |> 
 |>     $ git diff HEAD:GIT-VERSION-GEN maint:GIT-VERSION-GEN
 |>     diff --git a/HEAD:GIT-VERSION-GEN b/maint:GIT-VERSION-GEN
 |>     index 40adbf7..0d1a86c 100755
 |>     --- a/HEAD:GIT-VERSION-GEN
 |>     +++ b/maint:GIT-VERSION-GEN
 |>     @@ -1,7 +1,7 @@
 |>     ...
 |> 
 |> and neither "HEAD:GIT-VERSION-GEN" nor "maint:GIT-VERSION-GEN" is
 |> the file being modified ("GIT-VERSION-GEN" is).
 |
 |I thought "git apply" knows how to strip the rev part.

That would brighten the sky of the glorious future.  Perfect!

 |> I would understand if the upstream of the pipe were
 |> 
 |>     $ git diff HEAD maint -- GIT-VERSION-GEN | ...
 |> 
 |> though.

Yes, in this case it applies the patch.

 |> Needless to say, if the place "cd" goes is not a worktree controlled
 |> by git, then "git apply" would not know where the top-level of the
 |> target tree is, so even though the input with the corrected command
 |> on the upstream side of the pipe tells it which file is being
 |> modified, it needs to be told with the proper -p<n> parameter how
 |> many leading levels to strip.
 |
 |I think it's a common mistake to think of "git apply" as some sort of
 |magic extension of "patch" which can do anything that "patch" does and
 |more, and can be fed anything that "git diff" produces", figuring out by
 |itself what to do with it :)

This was indeed my mistake. But regardless i think the current behaviour sucks:

  ?0[steffen@sherwood x.git]$ git diff HEAD:XY 5d0d74:XY |
  > (cd src && patch -p4)
  can't find file to patch at input line 5
  Perhaps you used the wrong -p or --strip option?
  The text leading up to this was:
  ?130[steffen@sherwood x.git]$ git diff HEAD:XY 5d0d74:XY |
  > (cd src && git apply -p4)
  ?0[steffen@sherwood x.git]$

and

  ?0[steffen@sherwood groff.git]$ git diff HEAD:XY 5d0d74:XY |
  > (cd src && git apply -p2)
  ?0[steffen@sherwood groff.git]$ git diff HEAD:XY 5d0d74:XY |
  > (cd src && patch -p2)
  patching file XY
  ?0[steffen@sherwood groff.git]$ 

The number after `?' is the exit status of the last command, btw. Ciao (and yes, thanks a lot for git(1)!)

--steffen