Difference between revisions of "Git patch"
(Created page with "== Patches == See [http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ this very nice post!] === Make some work === git checkout -b fix In the new fix b...") |
(Forced creation of a TOC - this will improve the formatting on the main page 'Did you know...' section.) |
||
(7 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
+ | __TOC__ | ||
+ | |||
== Patches == | == Patches == | ||
See [http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ this very nice post!] | See [http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ this very nice post!] | ||
Line 5: | Line 7: | ||
git checkout -b fix | git checkout -b fix | ||
− | In the new fix branch you can hack whatever you need to fix. Write tests, update code etc. etc. | + | In the new fix branch you can hack whatever you need to fix. Write tests, update code etc. etc.<br> |
+ | # To only add updated files to commit stage | ||
+ | git add -u | ||
+ | # To make a commit | ||
+ | git commit -m "my commit message" | ||
When you’re satisfied with all you changes, it’s time to create your patch. We assume you made a few commits in the fix branch and did not yet merge it back in to the master branch. | When you’re satisfied with all you changes, it’s time to create your patch. We assume you made a few commits in the fix branch and did not yet merge it back in to the master branch. | ||
− | Check you changes | + | Check you changes |
− | git log --pretty=oneline - | + | git log |
+ | git log --pretty=oneline -5 | ||
=== Create patches === | === Create patches === | ||
Now create your patch, comparing to the master branch | Now create your patch, comparing to the master branch | ||
− | git format-patch master -- | + | git format-patch master --ignore-if-in-upstream |
+ | Now tar and gunzip the files | ||
+ | tar -cvzf fix.patch.tar.gz 00*.patch | ||
+ | rm 00*.patch | ||
+ | If you need to unpack (ungzip, unarchive) a tar.gz file | ||
+ | tar -xzf fix.patch.tar.gz | ||
Normally, git would create a separate patch file for each commit, but that’s not what we want. All we need is a single patch file. This will create a new file fix.patch with all changes from the current branch (fix) against master. | Normally, git would create a separate patch file for each commit, but that’s not what we want. All we need is a single patch file. This will create a new file fix.patch with all changes from the current branch (fix) against master. | ||
+ | |||
+ | Create one patch file, comparing to the master branch | ||
+ | git format-patch master --stdout --ignore-if-in-upstream > fix.patch | ||
Now, you have a patch for the fix you wrote. [[Bugs_and_development_wishes | Send it to the maintainer of the project.]] | Now, you have a patch for the fix you wrote. [[Bugs_and_development_wishes | Send it to the maintainer of the project.]] | ||
Line 34: | Line 49: | ||
Next, you’re interested in how troublesome the patch is going to be. Git allows you to test the patch before you actually apply it. | Next, you’re interested in how troublesome the patch is going to be. Git allows you to test the patch before you actually apply it. | ||
+ | git checkout master | ||
git apply --check fix.patch | git apply --check fix.patch | ||
If you don’t get any errors, the patch can be applied cleanly. <br> | If you don’t get any errors, the patch can be applied cleanly. <br> |
Latest revision as of 15:02, 15 October 2015
Contents
Patches
Make some work
git checkout -b fix
In the new fix branch you can hack whatever you need to fix. Write tests, update code etc. etc.
# To only add updated files to commit stage git add -u # To make a commit git commit -m "my commit message"
When you’re satisfied with all you changes, it’s time to create your patch. We assume you made a few commits in the fix branch and did not yet merge it back in to the master branch.
Check you changes
git log git log --pretty=oneline -5
Create patches
Now create your patch, comparing to the master branch
git format-patch master --ignore-if-in-upstream
Now tar and gunzip the files
tar -cvzf fix.patch.tar.gz 00*.patch rm 00*.patch
If you need to unpack (ungzip, unarchive) a tar.gz file
tar -xzf fix.patch.tar.gz
Normally, git would create a separate patch file for each commit, but that’s not what we want. All we need is a single patch file. This will create a new file fix.patch with all changes from the current branch (fix) against master.
Create one patch file, comparing to the master branch
git format-patch master --stdout --ignore-if-in-upstream > fix.patch
Now, you have a patch for the fix you wrote. Send it to the maintainer of the project.
Applying the patch
In subversion
patch -p1 < fix.patch
In git
The maintainer will take some steps, to check everything goes smooth.
First, we take a look at what changes are in the patch. You can do this easily with git apply.
git apply --stat fix.patch
This command does not apply the patch, but only shows you the stats about what it’ll do.
After peeking into the patch file with your favorite editor, you can see what the actual changes are.
Next, you’re interested in how troublesome the patch is going to be. Git allows you to test the patch before you actually apply it.
git checkout master git apply --check fix.patch
If you don’t get any errors, the patch can be applied cleanly.
Otherwise you may see what trouble you’ll run into.
To apply the patch, I’ll use git am instead of git apply.
The reason for this is that git am allows you to sign off an applied patch. This may be useful for later reference.
git am --signoff < fix.patch
Applying: Added specs to test empty poster URL behaviour Applying: Added poster URL as part of cli output
Okay, patches were applied cleanly and you’re master branch has been updated. Of course, run your tests again to make sure nothing got borked.
In you git log, you’ll find that the commit messages contain a “Signed-off-by” tag.
This tag will be read by Github and others to provide useful info about how the commit ended up in the code.