summaryrefslogtreecommitdiff
path: root/t/t4014-format-patch.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-11-21Merge branch 'jc/format-patch-name-max'Libravatar Junio C Hamano1-0/+54
The maximum length of output filenames "git format-patch" creates has become configurable (used to be capped at 64). * jc/format-patch-name-max: format-patch: make output filename configurable
2020-11-09format-patch: make output filename configurableLibravatar Junio C Hamano1-0/+54
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-04format-patch: support --output optionLibravatar Jeff King1-3/+23
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), 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", 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). Reported-by: Johannes Postler <johannes.postler@txture.io> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-04format-patch: refactor output selectionLibravatar Jeff King1-0/+13
The --stdout and --output-directory options are mutually exclusive, but it's hard to tell from reading the code. We have three separate conditionals that check for use_stdout, and it's only after we've set up the output_directory fully that we check whether the user also specified --stdout. Instead, let's check the exclusion explicitly first, then have a single conditional that handles stdout versus an output directory. This is slightly easier to follow now, and also will keep things sane when we add another output mode in a future patch. We'll add a few tests as well, covering the mutual exclusion and the fact that we are not confused by a configured output directory. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-01format-patch: teach format.useAutoBase "whenAble" optionLibravatar Jacob Keller1-0/+22
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-06-25Merge branch 'pb/t4014-unslave'Libravatar Junio C Hamano1-4/+4
A branch name used in a test has been clarified to match what is going on. * pb/t4014-unslave: t4014: do not use "slave branch" nomenclature
2020-06-19t4014: do not use "slave branch" nomenclatureLibravatar Paolo Bonzini1-4/+4
Git branches have been qualified as topic branches, integration branches, development branches, feature branches, release branches and so on. Git has a branch that is the master *for* development, but it is not the master *of* any "slave branch": Git does not have slave branches, and has never had, except for a single testcase that claims otherwise. :) Independent of any future change to the naming of the "master" branch, removing this sole appearance of the term is a strict improvement: it avoids divisive language, and talking about "feature branch" clarifies which developer workflow the test is trying to emulate. Reported-by: Till Maas <tmaas@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-24diff: add config option relativeLibravatar Laurent Arnoud1-0/+13
The `diff.relative` boolean option set to `true` shows only changes in the current directory/value specified by the `path` argument of the `relative` option and shows pathnames relative to the aforementioned directory. Teach `--no-relative` to override earlier `--relative` Add for git-format-patch(1) options documentation `--relative` and `--no-relative` Signed-off-by: Laurent Arnoud <laurent@spkdev.net> Acked-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-07format-patch: teach --no-encode-email-headersLibravatar Emma Brooks1-0/+53
When commit subjects or authors have non-ASCII characters, git format-patch Q-encodes them so they can be safely sent over email. However, if the patch transfer method is something other than email (web review tools, sneakernet), this only serves to make the patch metadata harder to read without first applying it (unless you can decode RFC 2047 in your head). git am as well as some email software supports non-Q-encoded mail as described in RFC 6531. Add --[no-]encode-email-headers and format.encodeEmailHeaders to let the user control this behavior. Signed-off-by: Emma Brooks <me@pluvano.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-25Merge branch 'dl/format-patch-notes-config-fixup'Libravatar Junio C Hamano1-0/+32
"git format-patch" can take a set of configured format.notes values to specify which notes refs to use in the log message part of the output. The behaviour of this was not consistent with multiple --notes command line options, which has been corrected. * dl/format-patch-notes-config-fixup: notes.h: fix typos in comment notes: break set_display_notes() into smaller functions config/format.txt: clarify behavior of multiple format.notes format-patch: move git_config() before repo_init_revisions() format-patch: use --notes behavior for format.notes notes: extract logic into set_display_notes() notes: create init_display_notes() helper notes: rename to load_display_notes()
2019-12-09format-patch: use --notes behavior for format.notesLibravatar Denton Liu1-0/+32
When we had multiple `format.notes` config values where we had `<ref1>`, `false`, `<ref2>` (in that order), then we would print out the notes for both `<ref1>` and `<ref2>`. This doesn't make sense, however, since we parse the config in a top-down manner and a `false` should be able to override previous configurations, just like how `--no-notes` will override previous `--notes`. Duplicate the logic that handles the `--[no-]notes[=]` option to `format.notes` for consistency. As a result, when parsing the config from top to bottom, `format.notes = true` will behave like `--notes`, `format.notes = <ref>` will behave like `--notes=<ref>` and `format.notes = false` will behave like `--no-notes`. This change isn't strictly backwards compatible but since it is an edge case where a sane user would not mix notes refs with `false` and this feature is relatively new (released only in v2.23.0), this change should be harmless. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-05format-patch: teach --no-baseLibravatar Denton Liu1-0/+6
If `format.useAutoBase = true`, there was no way to override this from the command-line. Teach the `--no-base` option in format-patch to override `format.useAutoBase`. Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-05t4014: use test_config()Libravatar Denton Liu1-5/+3
Instead of manually unsetting the config after the test case is done, use test_config() to do it automatically. While we're at it, fix a typo in a test case name. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Merge branch 'dl/format-patch-cover-from-desc'Libravatar Junio C Hamano1-0/+172
The branch description ("git branch --edit-description") has been used to fill the body of the cover letters by the format-patch command; this has been enhanced so that the subject can also be filled. * dl/format-patch-cover-from-desc: format-patch: teach --cover-from-description option format-patch: use enum variables format-patch: replace erroneous and condition
2019-10-24Merge branch 'bw/format-patch-o-create-leading-dirs'Libravatar Junio C Hamano1-5/+8
Test update. * bw/format-patch-o-create-leading-dirs: t4014: make output-directory tests self-contained
2019-10-23t4014: make output-directory tests self-containedLibravatar Bert Wesarg1-5/+8
As noted by Gábor in [1], the new tests in edefc31873 ("format-patch: create leading components of output directory", 2019-10-11) cannot be run independently. Fix this. [1] https://public-inbox.org/git/20191011144650.GM29845@szeder.dev/ Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18Merge branch 'bw/format-patch-o-create-leading-dirs'Libravatar Junio C Hamano1-0/+23
"git format-patch -o <outdir>" did an equivalent of "mkdir <outdir>" not "mkdir -p <outdir>", which is being corrected. * bw/format-patch-o-create-leading-dirs: format-patch: create leading components of output directory
2019-10-16format-patch: teach --cover-from-description optionLibravatar Denton Liu1-0/+172
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). Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-12format-patch: create leading components of output directoryLibravatar Bert Wesarg1-0/+23
'git format-patch -o <outdir>' 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. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-09t4014: treat rev-list output as the expected valueLibravatar Denton Liu1-2/+3
In 6bd26f58ea (t4014: use test_line_count() where possible, 2019-08-27), we converted many test cases to take advantage of the test_line_count() function. In one conversion, we inverted the expected and actual value as tested by test_line_count(). Although functionally correct, if format-patch ever produced incorrect output, the debugging output would be a bunch of hashes which would be difficult to debug. Invert the expected and actual values provided to test_line_count() so that if format-patch produces incorrect output, the debugging output will be a list of human-readable files instead. Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t4014: stop losing return codes of git commandsLibravatar Denton Liu1-77/+120
Currently, there are two ways where the return codes of Git commands are lost. The first way is when a command is in the upstream of a pipe. In a pipe, only the return code of the last command is used. Thus, all other commands will have their return codes masked. Rewrite pipes so that there are no Git commands upstream. The other way is when a command is in a non-assignment subshell. The return code will be lost in favour of the surrounding command's. Rewrite instances of this such that Git commands output to a file and surrounding commands only call subshells with non-Git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t4014: remove confusing pipe in check_threading()Libravatar Denton Liu1-3/+2
In check_threading(), there was a Git command in the upstream of a pipe. In order to not lose its status code, it was saved into a file. However, this may be confusing so rewrite to redirect IO to file. This allows us to directly use the conventional &&-chain. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t4014: use test_line_count() where possibleLibravatar Denton Liu1-16/+19
Convert all instances of `cnt=$(... | wc -l) && test $cnt = N` into uses of `test_line_count()`. While we're at it, convert one instance of a Git command upstream of a pipe into two commands. This prevents a failure of a Git command from being masked since only the return code of the last member of the pipe is shown. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t4014: let sed open its own filesLibravatar Denton Liu1-14/+14
In some cases, we were using a redirection operator to feed input into sed. However, since sed is capable of opening its own files, make sed open its own files instead of redirecting input into it. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t4014: drop redirections to /dev/nullLibravatar Denton Liu1-6/+6
Since output is silenced when running without `-v` and debugging output is useful with `-v`, remove redirections to /dev/null as it is not useful. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t4014: use indentable here-docsLibravatar Denton Liu1-184/+184
The convention is to use indentable here-docs within test cases so that the here-docs line up with the rest of the code within the test case. Change here-docs from `<<\EOF` to `<<-\EOF` so that they can be indented along with the rest of the test case. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t4014: remove spaces after redirect operatorsLibravatar Denton Liu1-31/+31
For shell scripts, the usual convention is for there to be no space after redirection operators, (e.g. `>file`, not `> file`). Remove these spaces wherever they appear. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t4014: use sq for test case namesLibravatar Denton Liu1-5/+5
The usual convention is for test case names to be written between single-quotes. Change all double-quoted test case names to single-quotes except for one test case name that uses a sq for a contraction. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t4014: move closing sq onto its own lineLibravatar Denton Liu1-2/+4
The usual convention for test cases is for the closing sq to be on its own line. Move the sq onto its own line for cases that do not conform to this style. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t4014: s/expected/expect/Libravatar Denton Liu1-53/+53
For test cases, the usual convention is to name expected output files "expect", not "expected". Replace all instances of "expected" with "expect", except for one case where the "expected" is used as the name of a test case. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-21t4014: drop unnecessary blank lines from test casesLibravatar Denton Liu1-47/+0
Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-13Merge branch 'dl/format-patch-notes-config'Libravatar Junio C Hamano1-0/+70
"git format-patch" learns a configuration to set the default for its --notes=<ref> option. * dl/format-patch-notes-config: format-patch: teach format.notes config option git-format-patch.txt: document --no-notes option
2019-05-17format-patch: teach format.notes config optionLibravatar Denton Liu1-0/+70
In git-format-patch, notes can be appended with the `--notes` option. However, this must be specified by the user on an invocation-by-invocation basis. If a user is not careful, it's possible that they may forget to include it and generate a patch series without notes. Teach git-format-patch the `format.notes` config option. Its value is a notes ref that will be automatically appended. The special value of "standard" can be used to specify the standard notes. This option is overridable with the `--no-notes` option in case a user wishes not to append notes. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08format-patch: make --base patch-id output stableLibravatar Stephen Boyd1-4/+4
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. Cc: Xiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08format-patch: inform user that patch-id generation is unstableLibravatar Stephen Boyd1-5/+31
I tried out 'git format-patch --base' with a set of commits that modifies more than one file. It turns out that the way this command is implemented it actually uses the unstable version of patch-id instead of the stable version that's documented. When I tried to modify the existing test to use 'git patch-id --stable' vs. 'git patch-id --unstable' I found that it didn't matter, the test still passed. Let's expand on the test here so it is a little more complicated and then use that to show that the patch-id generation is actually unstable vs. stable. Update the documentation as well. Cc: Xiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22format-patch: notice failure to open cover letter for writingLibravatar Junio C Hamano1-0/+6
The make_cover_letter() function is supposed to open a new file for writing, and let the caller write into it via FILE *rev->diffopt.file but because the function does not return anything, the caller does not bother checking the return value. Make sure it dies, instead of keep going with a NULL output filestream and relying on it to cause a crash, when it fails to open the file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-23format-patch: allow --interdiff to apply to a lone-patchLibravatar Eric Sunshine1-0/+12
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 into the commentary section of the lone patch of a 1-patch series. 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. Implementation note: Generating an interdiff for insertion into the commentary section of a patch which itself is currently being generated requires invoking the diffing machinery recursively. However, the machinery does not (presently) support this since it uses global state. Consequently, we need to take care to stash away the state of the in-progress operation while generating the interdiff, and restore it after. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-23format-patch: teach --interdiff to respect -v/--reroll-countLibravatar Eric Sunshine1-0/+5
The --interdiff option introduces the embedded interdiff generically as "Interdiff:", however, we can do better when --reroll-count is specified by emitting "Interdiff against v{n}:" instead. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-23format-patch: add --interdiff option to embed diff in cover letterLibravatar Eric Sunshine1-0/+17
When submitting a revised version of a patch series, it can be helpful (to reviewers) to include a summary of changes since the previous attempt in the form of an interdiff, however, doing so involves manually copy/pasting the diff into the cover letter. Add an --interdiff option to automate this process. The argument to --interdiff specifies the tip of the previous attempt against which to generate the interdiff. For example: git format-patch --cover-letter --interdiff=v1 -3 v2 The previous attempt and the patch series being formatted must share a common base. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-18Merge branch 'xy/format-patch-prereq-patch-id-fix'Libravatar Junio C Hamano1-2/+4
Recently added "--base" option to "git format-patch" command did not correctly generate prereq patch ids. * xy/format-patch-prereq-patch-id-fix: format-patch: clear UNINTERESTING flag before prepare_bases
2018-06-19format-patch: clear UNINTERESTING flag before prepare_basesLibravatar Xiaolong Ye1-2/+4
When users specify the commit range with 'Z..C' pattern for format-patch, all the parents of Z (including Z) would be marked as UNINTERESTING which would prevent revision walk in prepare_bases from getting the prerequisite commits, thus `git format-patch --base <base_commit_sha> Z..C` won't be able to generate the list of prerequisite patch ids. Clear UNINTERESTING flag with clear_object_flags solves this issue. Reported-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-30Merge branch 'bc/hash-independent-tests'Libravatar Junio C Hamano1-5/+8
Many tests hardcode the raw object names, which would change once we migrate away from SHA-1. While some of them must test against exact object names, most of them do not have to use hardcoded constants in the test. The latter kind of tests have been updated to test the moral equivalent of the original without hardcoding the actual object names. * bc/hash-independent-tests: (28 commits) t5300: abstract away SHA-1-specific constants t4208: abstract away SHA-1-specific constants t4045: abstract away SHA-1-specific constants t4042: abstract away SHA-1-specific constants t4205: sort log output in a hash-independent way t/lib-diff-alternative: abstract away SHA-1-specific constants t4030: abstract away SHA-1-specific constants t4029: abstract away SHA-1-specific constants t4029: fix test indentation t4022: abstract away SHA-1-specific constants t4020: abstract away SHA-1-specific constants t4014: abstract away SHA-1-specific constants t4008: abstract away SHA-1-specific constants t4007: abstract away SHA-1-specific constants t3905: abstract away SHA-1-specific constants t3702: abstract away SHA-1-specific constants t3103: abstract away SHA-1-specific constants t2203: abstract away SHA-1-specific constants t: skip pack tests if not using SHA-1 t4044: skip test if not using SHA-1 ...
2018-05-21t4014: abstract away SHA-1-specific constantsLibravatar brian m. carlson1-3/+6
Adjust the test so that it computes values for blobs instead of using hard-coded hashes. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-14t: switch $_x40 to $OID_REGEXLibravatar brian m. carlson1-1/+1
Switch all uses of $_x40 to $OID_REGEX so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/test-lib.sh: sed -i 's/\$_x40/$OID_REGEX/g' Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-14t: switch $_z40 to $ZERO_OIDLibravatar brian m. carlson1-1/+1
Switch all uses of $_z40 to $ZERO_OID so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/test-lib.sh: sed -i 's/\$_z40/$ZERO_OID/g' Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02format-patch: make cover letters always text/plainLibravatar brian m. carlson1-0/+9
When formatting a series of patches using --attach and --cover-letter, the cover letter lacks the closing MIME boundary, violating RFC 2046. Certain clients, such as Thunderbird, discard the message body in such a case. Since the cover letter is just one part and sending it as multipart/mixed is not very useful, always emit it as text/plain, avoiding the boundary problem altogether. Reported-by: Patrick Hemmer <git@stormcloud9.net> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-29sequencer: use trailer's trailer layoutLibravatar Jonathan Tan1-5/+32
Make sequencer use trailer.c's trailer layout definition, as opposed to parsing the footer by itself. This makes "commit -s", "cherry-pick -x", and "format-patch --signoff" consistent with trailer, allowing non-trailer lines and multiple-line trailers in trailer blocks under certain conditions, and therefore suppressing the extra newline in those cases. Consistency with trailer extends to respecting trailer configs. Tests have been included to show that. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26Merge branch 'jt/format-patch-rfc'Libravatar Junio C Hamano1-0/+9
In some projects, it is common to use "[RFC PATCH]" as the subject prefix for a patch meant for discussion rather than application. A new option "--rfc" was a short-hand for "--subject-prefix=RFC PATCH" to help the participants of such projects. * jt/format-patch-rfc: format-patch: add "--rfc" for the common case of [RFC PATCH]
2016-09-21format-patch: add "--rfc" for the common case of [RFC PATCH]Libravatar Josh Triplett1-0/+9
Add an alias for --subject-prefix='RFC PATCH', which is used commonly in some development communities to deserve such a short-hand. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-15format-patch: show base info before email signatureLibravatar Josh Triplett1-6/+27
Any text below the "-- " for the email signature gets treated as part of the signature, and many mail clients will trim it from the quoted text for a reply. Move it above the signature, so people can reply to it more easily. Similarly, when producing the patch as a MIME attachment, the original code placed the base info after the attached part, which would be discarded. Move the base info to the end of the part, still inside the part boundary. Add tests for the exact format of the email signature, and add tests to ensure that the base info appears before the email signature when producing a plain-text output, and that it appears before the part boundary when producing a MIME attachment. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>