Recently, we had to create a git patch
for the deployment of a 3rd party repository in our code.
Some of the changes we had to apply using the patch mechanism was the creation of a few new files.
We did not want to have an external script to copy the new files to the appropriate locations, so we had to include those new files in the git patch
somehow.
The git diff
command (with the parameter -p
or --patch
) that generates the patch, it ignored the untracked files and so they did not appear in the patch.
To make the untracked files visible to the git diff
command, we staged them (using git add
) and then used the following command to create the patch:
git diff --patch --staged;
git diff [--options] --cached [<commit>] [--] [<path>...]
git diff [--options] --staged [<commit>] [--] [<path>...]
Adding the parameter --staged
or --cached
allows you to view the changes you staged for the next commit relative to the named <commit>. Typically you would want comparison with the latest commit, so if you do not give <commit>, it defaults to HEAD. If HEAD does not exist (e.g. unborned branches) and <commit> is not given, it shows all staged changes. --staged
is a synonym of --cached
.
From: man git-diff
In the end our commands to create the patch with the new files and apply it on a new clone of the 3rd party repository was as follows:
#In the folder of the modified repository, where the new files are staged git diff -p --staged > ~/new.file.patch.diff; #In the folder of the new clone of the repository, where the new files need to be created git apply ~/new.file.patch.diff;
This post is also available in: Greek