2018-08-22 18:05:57 +02:00
|
|
|
format.attach::
|
|
|
|
|
Enable multipart/mixed attachments as the default for
|
|
|
|
|
'format-patch'. The value can also be a double quoted string
|
|
|
|
|
which will enable attachments as the default and set the
|
|
|
|
|
value as the boundary. See the --attach option in
|
|
|
|
|
linkgit:git-format-patch[1].
|
|
|
|
|
|
|
|
|
|
format.from::
|
|
|
|
|
Provides the default value for the `--from` option to format-patch.
|
|
|
|
|
Accepts a boolean value, or a name and email address. If false,
|
|
|
|
|
format-patch defaults to `--no-from`, using commit authors directly in
|
|
|
|
|
the "From:" field of patch mails. If true, format-patch defaults to
|
|
|
|
|
`--from`, using your committer identity in the "From:" field of patch
|
|
|
|
|
mails and including a "From:" field in the body of the patch mail if
|
|
|
|
|
different. If set to a non-boolean value, format-patch uses that
|
|
|
|
|
value instead of your committer identity. Defaults to false.
|
|
|
|
|
|
2022-08-29 23:38:37 +02:00
|
|
|
format.forceInBodyFrom::
|
|
|
|
|
Provides the default value for the `--[no-]force-in-body-from`
|
|
|
|
|
option to format-patch. Defaults to false.
|
|
|
|
|
|
2018-08-22 18:05:57 +02:00
|
|
|
format.numbered::
|
|
|
|
|
A boolean which can enable or disable sequence numbers in patch
|
|
|
|
|
subjects. It defaults to "auto" which enables it only if there
|
|
|
|
|
is more than one patch. It can be enabled or disabled for all
|
|
|
|
|
messages by setting it to "true" or "false". See --numbered
|
|
|
|
|
option in linkgit:git-format-patch[1].
|
|
|
|
|
|
|
|
|
|
format.headers::
|
|
|
|
|
Additional email headers to include in a patch to be submitted
|
|
|
|
|
by mail. See linkgit:git-format-patch[1].
|
|
|
|
|
|
|
|
|
|
format.to::
|
|
|
|
|
format.cc::
|
|
|
|
|
Additional recipients to include in a patch to be submitted
|
|
|
|
|
by mail. See the --to and --cc options in
|
|
|
|
|
linkgit:git-format-patch[1].
|
|
|
|
|
|
|
|
|
|
format.subjectPrefix::
|
|
|
|
|
The default for format-patch is to output files with the '[PATCH]'
|
|
|
|
|
subject prefix. Use this variable to change that prefix.
|
|
|
|
|
|
2019-10-15 11:06:40 +02:00
|
|
|
format.coverFromDescription::
|
|
|
|
|
The default mode for format-patch to determine which parts of
|
|
|
|
|
the cover letter will be populated using the branch's
|
|
|
|
|
description. See the `--cover-from-description` option in
|
|
|
|
|
linkgit:git-format-patch[1].
|
|
|
|
|
|
2018-08-22 18:05:57 +02:00
|
|
|
format.signature::
|
|
|
|
|
The default for format-patch is to output a signature containing
|
|
|
|
|
the Git version number. Use this variable to change that default.
|
|
|
|
|
Set this variable to the empty string ("") to suppress
|
|
|
|
|
signature generation.
|
|
|
|
|
|
|
|
|
|
format.signatureFile::
|
|
|
|
|
Works just like format.signature except the contents of the
|
|
|
|
|
file specified by this variable will be used as the signature.
|
|
|
|
|
|
|
|
|
|
format.suffix::
|
|
|
|
|
The default for format-patch is to output files with the suffix
|
|
|
|
|
`.patch`. Use this variable to change that suffix (make sure to
|
|
|
|
|
include the dot if you want it).
|
|
|
|
|
|
2020-04-08 06:31:38 +02:00
|
|
|
format.encodeEmailHeaders::
|
|
|
|
|
Encode email headers that have non-ASCII characters with
|
|
|
|
|
"Q-encoding" (described in RFC 2047) for email transmission.
|
|
|
|
|
Defaults to true.
|
|
|
|
|
|
2018-08-22 18:05:57 +02:00
|
|
|
format.pretty::
|
|
|
|
|
The default pretty format for log/show/whatchanged command,
|
|
|
|
|
See linkgit:git-log[1], linkgit:git-show[1],
|
|
|
|
|
linkgit:git-whatchanged[1].
|
|
|
|
|
|
|
|
|
|
format.thread::
|
|
|
|
|
The default threading style for 'git format-patch'. Can be
|
|
|
|
|
a boolean value, or `shallow` or `deep`. `shallow` threading
|
|
|
|
|
makes every mail a reply to the head of the series,
|
|
|
|
|
where the head is chosen from the cover letter, the
|
|
|
|
|
`--in-reply-to`, and the first patch mail, in this order.
|
|
|
|
|
`deep` threading makes every mail a reply to the previous one.
|
|
|
|
|
A true boolean value is the same as `shallow`, and a false
|
|
|
|
|
value disables threading.
|
|
|
|
|
|
|
|
|
|
format.signOff::
|
|
|
|
|
A boolean value which lets you enable the `-s/--signoff` option of
|
Documentation: stylistically normalize references to Signed-off-by:
Ted reported an old typo in the git-commit.txt and merge-options.txt.
Namely, the phrase "Signed-off-by line" was used without either a
definite nor indefinite article.
Upon examination, it seems that the documentation (including items in
Documentation/, but also option help strings) have been quite
inconsistent on usage when referring to `Signed-off-by`.
First, very few places used a definite or indefinite article with the
phrase "Signed-off-by line", but that was the initial typo that led
to this investigation. So, normalize using either an indefinite or
definite article consistently.
The original phrasing, in Commit 3f971fc425b (Documentation updates,
2005-08-14), is "Add Signed-off-by line". Commit 6f855371a53 (Add
--signoff, --check, and long option-names. 2005-12-09) switched to
using "Add `Signed-off-by:` line", but didn't normalize the former
commit to match. Later commits seem to have cut and pasted from one
or the other, which is likely how the usage became so inconsistent.
Junio stated on the git mailing list in
<xmqqy2k1dfoh.fsf@gitster.c.googlers.com> a preference to leave off
the colon. Thus, prefer `Signed-off-by` (with backticks) for the
documentation files and Signed-off-by (without backticks) for option
help strings.
Additionally, Junio argued that "trailer" is now the standard term to
refer to `Signed-off-by`, saying that "becomes plenty clear that we
are not talking about any random line in the log message". As such,
prefer "trailer" over "line" anywhere the former word fits.
However, leave alone those few places in documentation that use
Signed-off-by to refer to the process (rather than the specific
trailer), or in places where mail headers are generally discussed in
comparison with Signed-off-by.
Reported-by: "Theodore Y. Ts'o" <tytso@mit.edu>
Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>
Acked-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20 03:03:55 +02:00
|
|
|
format-patch by default. *Note:* Adding the `Signed-off-by` trailer to a
|
2018-08-22 18:05:57 +02:00
|
|
|
patch should be a conscious act and means that you certify you have
|
|
|
|
|
the rights to submit this work under the same open source license.
|
|
|
|
|
Please see the 'SubmittingPatches' document for further discussion.
|
|
|
|
|
|
|
|
|
|
format.coverLetter::
|
|
|
|
|
A boolean that controls whether to generate a cover-letter when
|
|
|
|
|
format-patch is invoked, but in addition can be set to "auto", to
|
|
|
|
|
generate a cover-letter only when there's more than one patch.
|
2019-08-27 06:05:20 +02:00
|
|
|
Default is false.
|
2018-08-22 18:05:57 +02:00
|
|
|
|
|
|
|
|
format.outputDirectory::
|
|
|
|
|
Set a custom directory to store the resulting files instead of the
|
2019-10-11 10:36:41 +02:00
|
|
|
current working directory. All directory components will be created.
|
2018-08-22 18:05:57 +02:00
|
|
|
|
format-patch: make output filename configurable
For the past 15 years, we've used the hardcoded 64 as the length
limit of the filename of the output from the "git format-patch"
command. Since the value is shorter than the 80-column terminal, it
could grow without line wrapping a bit. At the same time, since the
value is longer than half of the 80-column terminal, we could fit
two or more of them in "ls" output on such a terminal if we allowed
to lower it.
Introduce a new command line option --filename-max-length=<n> and a
new configuration variable format.filenameMaxLength to override the
hardcoded default.
While we are at it, remove a check that the name of output directory
does not exceed PATH_MAX---this check is pointless in that by the
time control reaches the function, the caller would already have
done an equivalent of "mkdir -p", so if the system does not like an
overly long directory name, the control wouldn't have reached here,
and otherwise, we know that the system allowed the output directory
to exist. In the worst case, we will get an error when we try to
open the output file and handle the error correctly anyway.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-06 22:56:24 +01:00
|
|
|
format.filenameMaxLength::
|
|
|
|
|
The maximum length of the output filenames generated by the
|
|
|
|
|
`format-patch` command; defaults to 64. Can be overridden
|
|
|
|
|
by the `--filename-max-length=<n>` command line option.
|
|
|
|
|
|
2018-08-22 18:05:57 +02:00
|
|
|
format.useAutoBase::
|
|
|
|
|
A boolean value which lets you enable the `--base=auto` option of
|
format-patch: teach format.useAutoBase "whenAble" option
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.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-01 23:46:53 +02:00
|
|
|
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.
|
2019-05-17 01:14:14 +02:00
|
|
|
|
|
|
|
|
format.notes::
|
|
|
|
|
Provides the default value for the `--notes` option to
|
|
|
|
|
format-patch. Accepts a boolean value, or a ref which specifies
|
|
|
|
|
where to get notes. If false, format-patch defaults to
|
|
|
|
|
`--no-notes`. If true, format-patch defaults to `--notes`. If
|
|
|
|
|
set to a non-boolean value, format-patch defaults to
|
|
|
|
|
`--notes=<ref>`, where `ref` is the non-boolean value. Defaults
|
|
|
|
|
to false.
|
|
|
|
|
+
|
|
|
|
|
If one wishes to use the ref `ref/notes/true`, please use that literal
|
|
|
|
|
instead.
|
|
|
|
|
+
|
|
|
|
|
This configuration can be specified multiple times in order to allow
|
2019-12-12 01:49:47 +01:00
|
|
|
multiple notes refs to be included. In that case, it will behave
|
|
|
|
|
similarly to multiple `--[no-]notes[=]` options passed in. That is, a
|
|
|
|
|
value of `true` will show the default notes, a value of `<ref>` will
|
|
|
|
|
also show notes from that notes ref and a value of `false` will negate
|
|
|
|
|
previous configurations and not show notes.
|
|
|
|
|
+
|
|
|
|
|
For example,
|
|
|
|
|
+
|
|
|
|
|
------------
|
|
|
|
|
[format]
|
|
|
|
|
notes = true
|
|
|
|
|
notes = foo
|
|
|
|
|
notes = false
|
|
|
|
|
notes = bar
|
|
|
|
|
------------
|
|
|
|
|
+
|
|
|
|
|
will only show notes from `refs/notes/bar`.
|