Git patch - Revision history

Bugman: Forced creation of a TOC - this will improve the formatting on the main page 'Did you know...' section.

2015-10-15T15:02:53Z

Forced creation of a TOC - this will improve the formatting on the main page 'Did you know...' section.

Tlinnet: /* Make some work */

2013-09-05T20:49:31Z

Make some work

Troels Emtekær Linnet: /* Create patches */

2013-08-02T19:48:44Z

Create patches

Troels Emtekær Linnet: /* Create patches */

2013-08-02T19:48:35Z

Create patches

Troels Emtekær Linnet: /* Create patches */

2013-08-02T19:48:23Z

Create patches

Troels Emtekær Linnet: /* Create patches */

2013-08-02T09:53:37Z

Create patches

Troels Emtekær Linnet: /* Create patches */

2013-08-02T09:47:03Z

Create patches

Tlinnet: /* In git */

2013-07-21T19:41:31Z

In git

Tlinnet: 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..."

2013-07-21T19:38:52Z

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..."

New page

== 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 branch you can hack whatever you need to fix. Write tests, update code etc. etc.

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 --pretty=oneline -3

=== Create patches ===
Now create your patch, comparing to the master branch
git format-patch master --stdout > fix.patch

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.

Now, you have a patch for the fix you wrote. [[Bugs_and_development_wishes | 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 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.

== See also ==
[[Category:Git]]

← Older revision		Revision as of 15:02, 15 October 2015
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 24: / Line 24: @@
 Create one patch file, comparing to the master branch
-  git format-patch master --stdout  --ignore-if-in-upstream > fix.patch
+  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.]]

@@ Line 24: / Line 24: @@
 Create one patch file, comparing to the master branch
-  git format-patch master --stdout > fix.patch
+  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.]]

@@ Line 14: / Line 14: @@
 === Create patches ===
 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

@@ Line 5: / Line 5: @@
   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>
 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 --pretty=oneline -3
+ git log
 === Create patches ===

@@ Line 34: / Line 34: @@
 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 apply --check fix.patch
 If you don’t get any errors, the patch can be applied cleanly. <br>