I need to write a script that creates patches for a list of SHA-1 commit numbers.
I tried using git format-patch <the SHA1>, but that generated a patch for each commit since that SHA-1 value. After a few hundred patches were generated, I had to kill the process.
Is there a way to generate a patch only for the specific SHA-1 value?
Try:
git format-patch -1 <sha>
or
git format-patch -1 HEAD
According to the documentation link above, the -1 flag tells Git how many commits should be included in the patch;
-<n>
Prepare patches from the topmost commits.
Apply the patch with the command:
git am < file.patch
This command (as suggested already by @Naftuli Tzvi Kay),
git format-patch -1 HEAD
Replace HEAD with a specific hash or range.
will generate the patch file for the latest commit formatted to resemble the Unix mailbox format.
-<n>- Prepare patches from the topmost <n> commits.
Then you can reapply the patch file in a mailbox format by:
git am -3k 001*.patch
See: man git-format-patch.
If you want to be sure the (single commit) patch will be applied on top of a specific commit, you can use the new git 2.9 (June 2016) option git format-patch --base
git format-patch --base=COMMIT_VALUE~ -M -C COMMIT_VALUE~..COMMIT_VALUE
# or
git format-patch --base=auto -M -C COMMIT_VALUE~..COMMIT_VALUE
# or
git config format.useAutoBase true
git format-patch -M -C COMMIT_VALUE~..COMMIT_VALUE
See commit bb52995, commit 3de6651, commit fa2ab86, commit ded2c09 (26 Apr 2016) by Xiaolong Ye (``).
(Merged by Junio C Hamano -- gitster -- in commit 72ce3ff, 23 May 2016)
format-patch: add '--base' option to record base tree info
Maintainers or third party testers may want to know the exact base tree the patch series applies to. Teach git format-patch a '
--base' option to record the base tree info and append it at the end of the first message (either the cover letter or the first patch in the series).The base tree info consists of the "base commit", which is a well-known commit that is part of the stable part of the project history everybody else works off of, and zero or more "prerequisite patches", which are well-known patches in flight that is not yet part of the "base commit" that need to be applied on top of "base commit" in topological order before the patches can be applied.
The "base commit" is shown as "
base-commit:" followed by the 40-hex of the commit object name.
A "prerequisite patch" is shown as "prerequisite-patch-id:" followed by the 40-hex "patch id", which can be obtained by passing the patch through the "git patch-id --stable" command.
Git 2.23 (Q3 2019) will improve that, because the "--base" option of "format-patch" computed the patch-ids for prerequisite patches in an unstable way, which has been updated to compute in a way that is compatible with "git patch-id --stable".
See commit a8f6855, commit 6f93d26 (26 Apr 2019) by Stephen Boyd (akshayka).
(Merged by Junio C Hamano -- gitster -- in commit 8202d12, 13 Jun 2019)
format-patch: make--base patch-idoutput stable
We weren't flushing the context each time we processed a hunk in the
patch-idgeneration code indiff.c, but we were doing that when we generated "stable" patch-ids with the 'patch-id' tool.Let's port that similar logic over from
patch-id.cintodiff.cso we can get the same hash when we're generating patch-ids for 'format-patch --base=' types of command invocations.
Before Git 2.24 (Q4 2019), "git format-patch -o <outdir>" did an equivalent of "mkdir <outdir>" not "mkdir -p <outdir>", which is being corrected.
See commit edefc31 (11 Oct 2019) by Bert Wesarg (bertwesarg).
(Merged by Junio C Hamano -- gitster -- in commit f1afbb0, 18 Oct 2019)
format-patch: create leading components of output directorySigned-off-by: Bert Wesarg
'git format-patch -o ' did an equivalent of '
mkdir <outdir>' not 'mkdir -p <outdir>', which is being corrected.
Avoid the usage of '
adjust_shared_perm' on the leading directories which may have security implications. Achieved by temporarily disabling of 'config.sharedRepository' like 'git init' does.
With Git 2.25 (Q1 2020), "git rebase" did not work well when format.useAutoBase configuration variable is set, which has been corrected.
See commit cae0bc0, commit 945dc55, commit 700e006, commit a749d01, commit 0c47e06 (04 Dec 2019) by Denton Liu (Denton-L).
(Merged by Junio C Hamano -- gitster -- in commit 71a7de7, 16 Dec 2019)
rebase: fixformat.useAutoBasebreakageReported-by: Christian Biesinger
Signed-off-by: Denton LiuWith
format.useAutoBase = true, running rebase resulted in an error:fatal: failed to get upstream, if you want to record base commit automatically, please use git branch --set-upstream-to to track a remote branch. Or you could specify base commit by --base=<base-commit-id> manually error: git encountered an error while preparing the patches to replay these revisions: ede2467cdedc63784887b587a61c36b7850ebfac..d8f581194799ae29bf5fa72a98cbae98a1198b12 As a result, git cannot rebase them.Fix this by always passing
--no-baseto format-patch from rebase so that the effect offormat.useAutoBaseis negated.
With Git 2.29 (Q4 2020), "git format-patch"(man) learns to take "whenAble" as a possible value for the format.useAutoBase configuration variable to become no-op when the automatically computed base does not make sense.
See commit 7efba5f (01 Oct 2020) by Jacob Keller (jacob-keller).
(Merged by Junio C Hamano -- gitster -- in commit 5f8c70a, 05 Oct 2020)
format-patch: teachformat.useAutoBase"whenAble" optionSigned-off-by: Jacob Keller
The
format.useAutoBaseconfiguration option exists to allow users to enable '--base=auto' for format-patch by default.This can sometimes lead to poor workflow, due to unexpected failures when attempting to format an ancient patch:
$ git format-patch -1 <an old commit> fatal: base commit shouldn't be in revision listThis can be very confusing, as it is not necessarily immediately obvious that the user requested a
--base(since this was in the configuration, not on the command line).We do want
--base=autoto fail when it cannot provide a suitable base, as it would be equally confusing if a formatted patch did not include the base information when it was requested.Teach
format.useAutoBasea new mode, "whenAble".This mode will cause format-patch to attempt to include a base commit when it can. However, if no valid base commit can be found, then format-patch will continue formatting the patch without a base commit.
In order to avoid making yet another branch name unusable with
--base, do not teach--base=whenAbleor--base=whenable.Instead, refactor the
base_commitoption to use a callback, and rely on the global configuration variableauto_base.This does mean that a user cannot request this optional base commit generation from the command line. However, this is likely not too valuable. If the user requests base information manually, they will be immediately informed of the failure to acquire a suitable base commit. This allows the user to make an informed choice about whether to continue the format.
Add tests to cover the new mode of operation for
--base.
git config now includes in its man page:
format-patchby default.
Can also be set to "whenAble" to allow enabling--base=autoif a suitable base is available, but to skip adding base info otherwise without the format dying.
With Git 2.30 (Q1 2021), "git format-patch --output=there"(man) did not work as expected and instead crashed.
The option is now supported.
See commit dc1672d, commit 1e1693b, commit 4c6f781 (04 Nov 2020) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit 5edc8bd, 18 Nov 2020)
format-patch: support --output optionReported-by: Johannes Postler
Signed-off-by: Jeff King
We've never intended to support diff's
--outputoption in format-patch. And until baa4adc66a (parse-options: disable option abbreviation withPARSE_OPT_KEEP_UNKNOWN,2019-01-27, Git v2.22.0-rc0), it was impossible to trigger. We first parse the format-patch options before handing the remainder off tosetup_revisions().
Before that commit, we'd accept "--output=foo" as an abbreviation for "--output-directory=foo". But afterwards, we don't check abbreviations, and --output gets passed to the diff code.This results in nonsense behavior and bugs. The diff code will have opened a filehandle at rev.diffopt.file, but we'll overwrite that with our own handles that we open for each individual patch file. So the --output file will always just be empty. But worse, the diff code also sets rev.diffopt.close_file, so
log_tree_commit()will close the filehandle itself. And then the main loop incmd_format_patch()will try to close it again, resulting in a double-free.The simplest solution would be to just disallow --output with format-patch, as nobody ever intended it to work. However, we have accidentally documented it (because format-patch includes diff-options). And it does work with "
git log"(man) , which writes the whole output to the specified file. It's easy enough to make that work for format-patch, too: it's really the same as --stdout, but pointed at a specific file.We can detect the use of the --output option by the
"close_file"flag (note that we can't use rev.diffopt.file, since the diff setup will otherwise set it to stdout). So we just need to unset that flag, but don't have to do anything else. Our situation is otherwise exactly like --stdout (note that we don't fclose() the file, but nor does the stdout case; exiting the program takes care of that for us).
With my Mercurial background I was going to use:
git log --patch -1 $ID > $file
But I am considering using git format-patch -1 $ID now.
