76

I would like to create a patch for the last 2 revisions.

git format-patch -2

gives me 2 patch files, one for each revision

git format-patch HEAD~2..HEAD

gives the same thing.

git format-patch -1 HEAD~2..HEAD

gives a single file, but only contains changes for the last revision.

Is there any way to do this in git?

Improve this question
4
  • 2
    Can you tell us more about the context of what you want to do? Are you aware of ability to squash commits together with interactive rebase? If so, why would you want to squash a patch you send to others but not the corresponding commits in your history? Commented Feb 7, 2010 at 21:04
  • @gbacon: I actually learned about rebase shortly after posting this question. You're right that it is a better solution to my problem. Still, it can't hurt to know how to do this. Commented Feb 7, 2010 at 22:15
  • 2
    @GregBacon: One thing I now do often is: Work in a feature branch, with many small commits. When it's time to push the branch to master, squash it first. But in the meantime, I use git diff master mybranch to send in a patch for review, while still preserving my small commit history (for my own use). Commented Aug 21, 2012 at 0:36
  • possible duplicate of How do you squash commits into one patch with git format-patch? Commented Aug 20, 2013 at 13:02

4 Answers 4

Reset to default
76

Use the --stdout option and then cat it to a file.

Like so:

git format-patch HEAD~2..HEAD --stdout > changes.patch

This will keep the per-commit metadata.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

What you get is an mbox file (concatenated mail files), not a patch file. You can apply it with git am. You won't be able to use the standard tools for patch files.
@Tobu: but often you want to apply the commits with git am, since that retains the commits as they are, instead of one big blob of code...
is there a way to reference the origin's HEAD as the beginning of the refspec?! That would be amazing something like git format-patch origin/HEAD..HEAD --stdout > changes.patch... OMG THAT WORKS
This solution is better than the one above - if there are binary files (for example secret files) then they will not be included in the above solution. This solution will also produce the full list of commits into one big patch file which is awesome - if you need to squash, it's possible using git rebase -i later on.
75 
git diff HEAD~2..HEAD > my-patch.diff

It won't have any of format-patch's per-commit metadata, though.

Improve this answer

3 Comments

Obviously. What author should it have if those two commits have different authors? How should the commit message for 2-commit change look like? Etc.
Note that if you use feature branches, you can just do git diff master mybranch > my-patch.diff to create a patch for that branch.
this method creates 3 files, not one.
5

With Git 2.20 (Q4 2018) and more, you now have:

  • git format-patch --interdiff.
  • git format-patch --rangediff.

Both are helping to explain the difference between this version and the previous attempt in the cover letter (or after the tree-dashes as a comment).

format-patch: allow --interdiff / --rangediff to apply to a lone-patch

When submitting a revised version of a patch or series, it can be helpful (to reviewers) to include a summary of changes since the previous attempt in the form of an interdiff, typically in the cover letter.
However, it is occasionally useful, despite making for a noisy read, to insert an interdiff or a rangediff into the commentary section of the lone patch of a 1-patch series.

See commit ee6cbf7, commit 3fcc7a2, commit 3b02641, commit 5ac290f, commit 126facf, commit fa5b7ea (22 Jul 2018) by Eric Sunshine (sunshineco).
(Merged by Junio C Hamano -- gitster -- in commit 688cb1c, 17 Sep 2018)

Therefore, extend "git format-patch --interdiff=<prev>" to insert an interdiff into the commentary section of a lone patch rather than requiring a cover letter.
The interdiff is indented to avoid confusing git-am and human readers into considering it part of the patch proper.

See commit 40ce416, commit 8631bf1, commit 4ee9968, commit 2e6fd71, commit 31e2617, commit 73a834e, commit 2566865, commit 87f1b2d (22 Jul 2018) by Eric Sunshine (sunshineco).
(Merged by Junio C Hamano -- gitster -- in commit 881c019, 17 Sep 2018)

Therefore, extend "git format-patch --range-diff=<refspec>" to insert a range-diff into the commentary section of a lone patch rather than requiring a cover letter.

With Git 2.46 (Q3 2024), batch 15, "git format-patch --interdiff"(man) for multi-patch series learned to turn on cover letters automatically (unless told never to enable cover letter with "--no-cover-letter" and such).

See commit f96c385, commit bc665cd (07 Jun 2024) by Rubén Justo (rjusto).
(Merged by Junio C Hamano -- gitster -- in commit 9071453, 20 Jun 2024)

format-patch: assume --cover-letter for diff in multi-patch series

Signed-off-by: Rubén Justo

When we deal with a multi-patch series in git-format-patch(1), if we see --interdiff or --range-diff but no --cover-letter, we return with an error, saying:

fatal: --range-diff requires --cover-letter or single patch

or:

fatal: --interdiff requires --cover-letter or single patch

This makes sense because the cover-letter is where we place the diff from the previous version.

However, considering that format-patch generates a multi-patch as needed, let's adopt a similar "cover as necessary" approach when using --interdiff or --range-diff.

Therefore, relax the requirement for an explicit --cover-letter in a multi-patch series when the user says --iterdiff or --range-diff.

Still, if only to return the error, respect "format.coverLetter=no" and --no-cover-letter.

Improve this answer

2 Comments

So, git format-patch --range-diff=<commit hash> produces a patch with just the commits needed, and no PATCH letter with each file changed?
@ZeroPhase no patch letter, as far as I know. (git-scm.com/docs/git-format-patch#Documentation/…)
-2

You could do something like:

 $ git checkout -b tmp $ git reset HEAD~2 $ git commit -a

The commit to branch tmp will be the same as the 2 individual commits.

Improve this answer

6 Comments

or git rebase -i HEAD~2, and squash.
Huh, a down vote on an answer that is well over 6 years old! That's some serious archeology. A comment would have been nice to explain the necrophilia.
I’m not the downvoter, but I’d suppose it’s because there is easier and safer ways to do it; git reset can eradicate something extra. The rebase given in a comment would be a bit safer since it would at least tell if the work tree is dirty. That said, I do think this answer has value.
This answer helped me since I needed to deal with well over 20 commits...
This is a dangerous way to do things if you have added new files / renamed them.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.