How do patches work in Git?

Question

I'm new to Git, but familiar with SVN. As a test I made a repository in a local directory with git init. Then I cloned the empty repository (over SSH using 127.0.0.1, which is another thing I wanted to test) to another local directory. I added some files in repository 2, I did git add * and finally git commit -a -m "First source code".

I now want to create a patch using git format-patch and apply it on repository 1. How do I do this? I know there's a manual, but these things are terribly complicated and make me wanna do certain things to my monitor.

Answer 1

Create your patch via:

$ git format-patch master --stdout > patch.diff

then patch.diff will contain the diff, which you can then send to someone else to apply using:

$ git am < patch.diff

Sometimes, when the manuals are a little dense, it makes sense to look for a tutorial:

http://luhman.org/blog/2009/09/22/git-patch-tutorial

Answer 2

The easiest method to create patches from the last commit (or last few commits) is to use format-patch with a negative number indicating the number of commits to create patches for:

git format-patch -1

You'll get a patch file named after the commit description. The use am to insert it into another repository:

git am << name_of_patch_file

Answer 3

Using GitHub patch

1. Add .patch to a commit URL to get the patch file, example

   github.com/git/git/commit/b6b3b6a.patch

2. Patch the original file like this:

   git am /tmp/b6b3b6a.patch
   

Using GitHub diff

1. Add .diff to a commit URL to get the patch file, example

   github.com/git/git/commit/b6b3b6a.diff

2. Patch the original file like this:

   git apply -p0 /tmp/b6b3b6a.diff
   

§5.3 Distributed Git - Maintaining a Project

Answer 4

The proper and easier way to do this if you're using Git is via remotes:

cd \path\to\repo1
git remote add otherrepo \path\to\repo2
git fetch otherrepo

git log otherrepo/master  ## Find the commit you want to steal in the list

git cherry-pick SOME_SHA1  ## Snag just one commit
git merge otherrepo/master  ## Merge all of the new commits from otherrepo/master

This will migrate commits from one repo to another, including their authors and commit messages, and will help you sort out merge conflicts (especially if you're moving > 1 commit)

Answer 5

With Git 2.25 (Q1 2020), git format-patch evolves to better use the branch description ("git branch --edit-description") as subject.

See commit bf8e65b, commit a92331d, commit 46273df (15 Oct 2019) by Denton Liu (Denton-L).
^{(Merged by Junio C Hamano -- gitster -- in commit b75ba9b, 10 Nov 2019)}

format-patch: teach --cover-from-description option

^{Signed-off-by: Denton Liu}

Before, when format-patch generated a cover letter, only the body would be populated with a branch's description while the subject would be populated with placeholder text.

However, users may want to have the subject of their cover letter automatically populated in the same way.

Teach format-patch to accept the --cover-from-description option and corresponding format.coverFromDescription config, allowing users to populate different parts of the cover letter (including the subject now).

The git config documentation now includes:

format.coverFromDescription:

The default mode for format-patch to determine which parts of the cover letter will be populated using the branch's description.

And git format-patch:

--cover-from-description=<mode>:

Controls which parts of the cover letter will be automatically populated using the branch's description.

• If <mode> is message or default, the cover letter subject will be populated with placeholder text.
  The body of the cover letter will be populated with the branch's description. This is the default mode when no configuration nor command line option is specified.

• If <mode> is subject, the first paragraph of the branch description will populate the cover letter subject.
  The remainder of the description will populate the body of the cover letter.

• If <mode> is auto, if the first paragraph of the branch description is greater than 100 bytes, then the mode will be message, otherwise subject will be used.

• If <mode> is none, both the cover letter subject and body will be populated with placeholder text.

---

On the cover letter itself, Git 2.37 (Q3 2022) explains:

See commit 4ec5008, commit c2cd4b5, commit e97d474, commit afc8c92, commit 489ef3b (12 May 2022) by Philippe Blain (phil-blain).
^{(Merged by Junio C Hamano -- gitster -- in commit 3ce9483, 25 May 2022)}

MyFirstContribution: add standalone section on cover letter

^{Signed-off-by: Philippe Blain}

An explanation of the purpose of the cover letter is included in the "Sending Patches with git send-email^(man) / Preparing Email section but is missing from the Sending Patches via GitGitGadget section.

Add a standalone section "The cover letter" under the "Getting Started: Anatomy of a Patch Series" header to explain what the cover letter is used for and to draft the cover letter of the 'psuh' topic used in the tutorial.

Note: psuh comes from:

In this tutorial, we will add a new command, +git psuh+, short for "Pony Saying 'Um, Hello" - a feature which has gone unimplemented despite a high frequency of invocation during users' typical daily workflow.

MyFirstContribution now includes in its man page:

Subsequent iterations of the patch series are labelled "PATCH v2", "PATCH v3", etc. in place of "PATCH".
For example, "[PATCH v2 1/3]" would be the first of three patches in the second iteration.

Each iteration is sent with a new cover letter (like "[PATCH v2 0/3]" above), itself a reply to the cover letter of the previous iteration (more on that below).

NOTE: A single-patch topic is sent with "[PATCH]", "[PATCH v2]", etc. without i/n numbering (in the above thread overview, no single-patch topic appears, though).

The cover letter

In addition to an email per patch, the Git community also expects your patches to come with a cover letter. This is an important component of change submission as it explains to the community from a high level what you're trying to do, and why, in a way that's more apparent than just looking at your patches.

The title of your cover letter should be something which succinctly covers the purpose of your entire topic branch. It's often in the imperative mood, just like our commit message titles. Here is how we'll title our series:

---

Add the 'psuh' command

The body of the cover letter is used to give additional context to reviewers. Be sure to explain anything your patches don't make clear on their own, but remember that since the cover letter is not recorded in the commit history, anything that might be useful to future readers of the repository's history should also be in your commit messages.

Here's an example body for psuh:

---

Our internal metrics indicate widespread interest in the command git-psuh - that is, many users are trying to use it, but finding it is unavailable, using some unknown workaround instead.

The following handful of patches add the psuh command and implement some handy features on top of it.

This patchset is part of the MyFirstContribution tutorial and should not be merged.

---

Answer 6

You have to go to "repository 2", the one you want to create the patch from, and run git-format-patch to create the patch : git format-patch master --stdout > name_of_patch_file

Then you go in "repository 1", the one you want to apply the patch to : git apply name_of_patch_file

Sometimes it is useful to just check if the patch will cause problems : git apply --check name_of_patch_file