How to apply a git patch from one repository to another?

Question

I have two repositories, one is the main repo for a library, and the other is a project using that library.

If I make a fix to the in the subservient project, I'd like an easy way to apply that patch back upstream.

The file's location is different in each repository.

• Main repo: www.playdar.org/static/playdar.js
• Project: playlick.com/lib/playdar.js

I tried using git format-patch -- lib/playdar.js on the playlick project, and then git am on the main playdar repo, but the differing file locations in the patch file raised an error.

Is there an easy way to apply the patch from a given commit on a given file to another arbitrary file elsewhere?

For bonus points, what if the file you want to apply the patch to isn't in a git repository?

Answer 1

If manually editing the patch file is out of the question or infeasible, this can be done with standard options (available in git apply, git format-patch and GNU patch).

1. -p<n> removes n leading directories from the paths in the patch.

2. After processing -p, --directory=<root> prepends root to each of the paths in the patch before applying.

Example

So, for your example, to take a patch that was originally on static/playdar.js and apply it to lib/playdar.js, you would run:

$ cat patch_file | git am     \ 
          -p1                 \ # remove 1 leading directory ('static/')
         --directory='lib/'     # prepend 'lib/'

Answer 2

The patch produced by git format-patch is simply a text file-- you can edit the diff headers so that it modifies a different path.

So for instance it would have produced something like this:

diff --git a/lib/playdar.js b/lib/playdar.js
index 1234567..89abcde
-- a/lib/playdar.js
++ b/lib/playdar.js

All you have to do is change lib/playdar.js to static/playdar.js and then run the patch through git am"

The patch should be readable by the standard GNU patch utility for people who don't have git--- but don't run format-patch with the -M, -C etc. options to produce rename patches in that case, because the support for them isn't universal.

Answer 3

Assuming both projects are git projects, it sounds like that submodules would be the perfect fit for you. This allows a git project dynamically link to another git project, essentially baking a git repo right inside another git repo, both having their own distinct lives.

In other words, add "main repo" as a submodule in "project". Whenever you commit/push new stuff in "main repo", you just git pull them back into "project".

Answer 4

To complete Henrik's answer, and to go for the bonus point

what if the file you want to apply the patch to isn't in a git repository?

If you have access to the directories of the file candidate for a patch coming from a git repository, you could first transform that tree of directories/files into a git repository itself! ('git init': a git repository is just a .git within a root directory after all).
Then you would set that repo as a submodule for your main project.

Answer 5

You can add a new remote and pull from it. Article with details.

$ cd <path-to-repoB>
$ git remote add repoA <git-URL-for-repoA>
$ git pull repoA

Answer 6

I think subtree is the best solution for your problem

Tutorial 1

Tuorial 2

Answer 7

You can just remove (rename) temporarily the main repository.

cd to/main/project
mv .git .git_
cd to/sub/project
git apply patchname
cd -
mv .git_ .git

Answer 8

Using the --relative option to format-patch can improve the abstraction (hide irrelevant details about the repository from which the patch was generated).

[repository-with-changes]
git format-patch --relative=(path-to-library) (base-commit-for-patch) ## 'HEAD~1'

I have found the --3way option to be required when applying the patch (to avoid does not exist in index error) -- your mileage may vary. Using --directory=(...) is likely only necessary if your target path is not the root of the repository.

[repository-to-update]
git am --3way --directory=(path-to-library) (patch-file)

---

• format-patch will create one patch file per commit to the current branch since 'base'.

• The documentation for the --relative option seems to be missing in some cases, but it appears to work anyway (as of version 2.7.4).