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-id
output stable
We weren't flushing the context each time we processed a hunk in the
patch-id
generation code in diff.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.c
into diff.c
so 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 directory
Signed-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
: fix format.useAutoBase
breakage
Reported-by: Christian Biesinger
Signed-off-by: Denton Liu
With 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-base
to format-patch from rebase so that the effect of format.useAutoBase
is 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
: teach format.useAutoBase
"whenAble
" option
Signed-off-by: Jacob Keller
The format.useAutoBase
configuration 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 list
This 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=auto
to 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.useAutoBase
a 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=whenAble
or --base=whenable
.
Instead, refactor the base_commit
option to use a callback, and rely on the global configuration variable auto_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-patch
by default.
Can also be set to "whenAble
" to allow
enabling --base=auto
if 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 option
Reported-by: Johannes Postler
Signed-off-by: Jeff King
We've never intended to support diff's --output
option in format-patch.
And until baa4adc66a (parse-options: disable option abbreviation with PARSE_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 to setup_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 in cmd_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).