threads / discuss / 28193

Behaviour of git apply --directory

Subject: Behaviour of git apply --directory

## tl;dr

3 messages between Aug 22, 2011 and Aug 24, 2011.

replies: 2people: 2as markdown or json

Andrew Berry· Aug 22, 2011, 15:21 UTC · lore
Hi,
The behaviour of git apply --directory seems a little confusing. It looks to be dependent on the current directory, but I can't use relative paths to apply a patch in one directory to a sibling directory. Absolute paths don't work either. I'd expected the parameter to either be relative to the git repository root, or to expand relative directories.
Any thoughts?
--Andrew
Junio C Hamano· Aug 22, 2011, 18:28 UTC · re: Andrew Berry · lore

Re: Behaviour of git apply --directory

Andrew Berry <andrewberry@sentex.net> writes:
Show 5 quoted lines
> The behaviour of git apply --directory seems a little confusing. It
> looks to be dependent on the current directory, but I can't use relative
> paths to apply a patch in one directory to a sibling directory. Absolute
> paths don't work either. I'd expected the parameter to either be
> relative to the git repository root, or to expand relative directories.

I do not think that parameter does not have anything to do with your cwd. As the documentation says:

  --directory=<root>::
          Prepend <root> to all filenames.  If a "-p" argument was also passed,
          it is applied before prepending the new root.
  For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh`
  can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by
  running `git apply --directory=modules/git-gui`.

the parameter is just a fixed string that is used to modify the path that appears in the patch before it gets applied, and has nothing to do with your current (or previous for that matter) working directory.

Suppose you have a patch that tries to update "COPYING". Such a patch generated by Git would look like this:

    diff --git a/COPYING b/COPYING
    index 536e555..ee559b1 100644
    --- a/COPYING
    +++ b/COPYING
    @@ -1,3 +1,4 @@
    +GPL GPL GPL
      Note that the only valid version of the GPL as far as this project
      is concerned is _this_ particular version of the license (ie v2, not

Further suppose that you have already rearranged your project so that that file appears in licenses/gpl directory, and your $(cwd) is licenses/ subdirectory of your working tree.

You would give --directory=licenses/gpl/ without passing any custom -p parameter. This internally turns the patch being applied into something like:

    diff --git a/licenses/gpl/COPYING b/licenses/gpl/COPYING
    index 536e555..ee559b1 100644
    --- a/licenses/gpl/COPYING
    +++ b/licenses/gpl/COPYING
    @@ -1,3 +1,4 @@
    +GPL GPL GPL
      Note that the only valid version of the GPL as far as this project
      is concerned is _this_ particular version of the license (ie v2, not

Because the patch application in git is always relative to the top level of your working tree no matter where you are, this applies to the path you intended it to.

Here is a sample transcript to try it yourself.
    $ (echo GPL GPL GPL; cat COPYING) >x && cat x >COPYING
    $ git diff >P.diff
    $ git checkout COPYING
    $ mkdir -p licenses/gpl
    $ git mv COPYING licenses/gpl
    $ cd licenses
    $ git apply -v --directory=licenses/gpl ../P.diff
    Checking patch licenses/gpl/COPYING...
    Applied patch licenses/gpl/COPYING cleanly.
    $ git diff
    diff --git a/licenses/gpl/COPYING b/licenses/gpl/COPYING
    index 536e555..ee559b1 100644
    --- a/licenses/gpl/COPYING
    +++ b/licenses/gpl/COPYING
    @@ -1,3 +1,4 @@
    +GPL GPL GPL
      Note that the only valid version of the GPL as far as this project
      is concerned is _this_ particular version of the license (ie v2, not
Andrew Berry· Aug 24, 2011, 14:26 UTC · re: Junio C Hamano · lore

Re: Behaviour of git apply --directory

Thanks for your detailed explanation.
On 2011-08-22, at 2:28 PM, Junio C Hamano wrote:
> Because the patch application in git is always relative to the top level
> of your working tree no matter where you are, this applies to the path you
> intended it to.
This is where I see the issue. For some reason when I specify --directory, I do have to be somewhere in the directory tree that the patch is going to be applied to. For example, in the following it works if my cwd is the repository root, or src, but not patches.

$ find . -not -path '*.git*' . ./patches ./patches/LICENSE.patch ./src ./src/LICENSE.txt $ git status # On branch master nothing to commit (working directory clean) $ cat patches/LICENSE.patch

diff --git a/LICENSE.txt b/LICENSE.txt
index 2c095c8..64ee213 100644
--- a/LICENSE.txt
+++ b/LICENSE.txt
@@ -1,3 +1,4 @@
+GPL GPL GPL
 GNU GENERAL PUBLIC LICENSE
 
               Version 2, June 1991
$ cd patches
$ git apply -v --directory=src LICENSE.patch
$ git status
# On branch master
nothing to commit (working directory clean)
$ cd ..
$ git apply -v --directory=src patches/LICENSE.patch
Checking patch src/LICENSE.txt...
Applied patch src/LICENSE.txt cleanly.
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   src/LICENSE.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout src
$ cd src
$ git apply -v --directory=src ../patches/LICENSE.patch
Checking patch src/LICENSE.txt...
Applied patch src/LICENSE.txt cleanly.
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   LICENSE.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

← back to recent threads