Skip to content

git and patches

July 2, 2011

Sometimes you want to send or receive patches of work done. I found this great tutorial on how you can do that using git, which I will briefly rewrite.

How to create patches using git?

I assume you have cloned the original repository, and created five commits that you want to send back to one of the developers. My favourite way to do that is by

git format-patch HEAD~5

The command will create five separate patch files, which you can attach to an e-mail and send. The ~5 means "the fifth commit before", in other words, the sixth last commit. That would be the last commit that are already in upstream, which you are not interested in. Assuming the work is done on the master branch and the remote repository is called origin, you could also do

git format-patch origin/master

which will do the same, create one patch file per commit since the commit which is already in origin/master.

How to receive patches?

The patches includes a header which contains the commit message, and author information. Normally you want to keep that. The initial thought is probably to use

git apply file.patch

However, this will only apply the changes, not commit them. Instead, one should first use the apply command to check that the patch is OK:

git apply --check file.patch

If you do not receive an error, it means that the patch will apply without failing. The way to apply it then is using

git am --signoff file.patch

This will commit the patch with original author information, and append to the commit message that it was signed off by you. The patches are numbered, starting with 0001. After you have committed all the patches to your own tree, you should make sure that they are in fact correct. If you find problems, you can always use rebase to remove commits again.

git rebase -i HEAD~5

will open an editor where you can select commits that you want to change. You can delete commits simply by deleting the corresponding line.

That’s it, now you can in an efficient and controlled way distribute and receive patches even when the repositories are not stored in a publicly available place!

9 Comments leave one →
  1. FiL permalink
    February 6, 2012 1:31 pm

    Hi! The only tutorial that really helped me..One question though: If you apply the last patch, does this mean that all the previous changes(in the other 4) are also included or you have to apply each one sequentially ?

    • February 7, 2012 7:12 am

      Hi FiL,

      If you only apply the last patch you will only apply that one. If that one depends on changes from another patch then it will most likely fail, something you will notice with the “git apply –check” command.

  2. pavlo permalink
    March 26, 2012 6:31 pm

    Hi! Sorry for my English. I have question about patching at all. Patch is what some particular commit have done or how project changed since previous commit – ok? For example, when I am cherry-picking commit it applies it as patch to my current branch – ok? So the main question is: when this patch is somewhat dependant on previous commit (realy it is anyway dependant on some of previous commit – yup?) what git makes or what is it’s algorithm to apply that patch? There are always some changes that are inseparable despite of the fact that they may be in different commits. Thank you

    • March 26, 2012 8:57 pm

      Sometimes cherry-picking will not work. Typically if a line just next to a changed one has been changed in another commit which isn’t in the current branch. You will then get a “merge conflict” I believe, where you have to manually fix afterwards.

      • pavlo permalink
        March 27, 2012 9:29 am

        Thank you for your answer. I also believe it is so. But don’t you find this logic a bit fuzzy? Well for me it’s interesting to read how exactly that works i.e. what commit is as a separate entity – i.e. what is patch? Does git remembers line numbers it changes? or what? But if so, when cherry picking we have nothing to do with that line numbers in new (current) branch. I dont want to read sources, but I also don’t think I can read about this anywhere else. But this unpredictability (or misunderstood) makes me crazy )

      • March 27, 2012 11:09 am

        You can have a look yourself by using “git diff” or gitk. That shows how a patch looks like. A patch consist of the edits plus 2-3 lines before and after each change, plus the information about line numbers. If the line numbers are slightly off but the exact same lines before/after the changes are found, the cherry-picking will succeed perhaps with a warning. If some of the lines before/after have also changed later on, the cherry-picking will fail because there is no way for git to safely figure out where the change should take place.

  3. pavlo permalink
    March 27, 2012 5:04 pm

    Oh you rock! Thank you.

  4. August 12, 2014 6:32 am

    How to fix patch file does not match with the current context…please explain me

  5. August 12, 2014 6:35 am

    I am able to create a patch …..How to apply it in other repository…….After downoading a patch where i need to save them… well as how to apply it ….while i am trying to apply a patch …..i am getting current context does not match with the file(text.docx).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: