summaryrefslogtreecommitdiff
path: root/t/t4014-format-patch.sh
AgeCommit message (Collapse)AuthorFilesLines
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>
2016-08-10Merge branch 'jt/format-patch-from-config'Libravatar Junio C Hamano1-0/+40
"git format-patch" learned format.from configuration variable to specify the default settings for its "--from" option. * jt/format-patch-from-config: format-patch: format.from gives the default for --from
2016-08-01format-patch: format.from gives the default for --fromLibravatar Josh Triplett1-0/+40
This helps users who would prefer format-patch to default to --from, and makes it easier to change the default in the future. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06Merge branch 'ew/mboxrd-format-am'Libravatar Junio C Hamano1-0/+41
Teach format-patch and mailsplit (hence "am") how a line that happens to begin with "From " in the e-mail message is quoted with ">", so that these lines can be restored to their original shape. * ew/mboxrd-format-am: am: support --patch-format=mboxrd mailsplit: support unescaping mboxrd messages pretty: support "mboxrd" output format
2016-06-10Merge branch 'jk/shell-portability'Libravatar Junio C Hamano1-1/+1
test fixes. * jk/shell-portability: t5500 & t7403: lose bash-ism "local" test-lib: add in-shell "env" replacement
2016-06-06pretty: support "mboxrd" output formatLibravatar Eric Wong1-0/+41
This output format prevents format-patch output from breaking readers if somebody copy+pasted an mbox into a commit message. Unlike the traditional "mboxo" format, "mboxrd" is designed to be fully-reversible. "mboxrd" also gracefully degrades to showing extra ">" in existing "mboxo" readers. This degradation is preferable to breaking message splitting completely, a problem I've seen in "mboxcl" due to having multiple, non-existent, or inaccurate Content-Length headers. "mboxcl2" is a non-starter since it's inherits the problems of "mboxcl" while being completely incompatible with existing tooling based around mailsplit. ref: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/mail-mbox-formats.html Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01test-lib: add in-shell "env" replacementLibravatar Jeff King1-1/+1
The one-shot environment variable syntax: FOO=BAR some-program is unportable when some-program is actually a shell function, like test_must_fail (on some shells FOO remains set after the function returns, and on others it does not). We sometimes get around this by using env, like: test_must_fail env FOO=BAR some-program But that only works because test_must_fail's arguments are themselves a command which can be run. You can't run: env FOO=BAR test_must_fail some-program because env does not know about our shell functions. So there is no equivalent for test_commit, for example, and one must resort to: ( FOO=BAR export FOO test_commit ) which is a bit verbose. Let's add a version of "env" that works _inside_ the shell, by creating a subshell, exporting variables from its argument list, and running the command. Its use is demonstrated on a currently-unportable case in t4014. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-23Merge branch 'xy/format-patch-base'Libravatar Junio C Hamano1-0/+105
"git format-patch" learned a new "--base" option to record what (public, well-known) commit the original series was built on in its output. * xy/format-patch-base: format-patch: introduce format.useAutoBase configuration format-patch: introduce --base=auto option format-patch: add '--base' option to record base tree info patch-ids: make commit_patch_id() a public helper function
2016-04-26format-patch: introduce format.useAutoBase configurationLibravatar Xiaolong Ye1-0/+19
This allows to record the base commit automatically, it is equivalent to set --base=auto in cmdline. The format.useAutoBase has lower priority than command line option, so if user set format.useAutoBase and pass the command line option in the meantime, base_commit will be the one passed to command line option. Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-26format-patch: introduce --base=auto optionLibravatar Xiaolong Ye1-0/+39
Introduce --base=auto to record the base commit info automatically, the base_commit will be the merge base of tip commit of the upstream branch and revision-range specified in cmdline. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-26format-patch: add '--base' option to record base tree infoLibravatar Xiaolong Ye1-0/+47
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. Imagine that on top of the public commit P, you applied well-known patches X, Y and Z from somebody else, and then built your three-patch series A, B, C, the history would be like: ---P---X---Y---Z---A---B---C With "git format-patch --base=P -3 C" (or variants thereof, e.g. with "--cover-letter" of using "Z..C" instead of "-3 C" to specify the range), the base tree information block is shown at the end of the first message the command outputs (either the first patch, or the cover letter), like this: base-commit: P prerequisite-patch-id: X prerequisite-patch-id: Y prerequisite-patch-id: Z Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25diff: activate diff.renames by defaultLibravatar Matthieu Moy1-2/+2
Rename detection is a very convenient feature, and new users shouldn't have to dig in the documentation to benefit from it. Potential objections to activating rename detection are that it sometimes fail, and it is sometimes slow. But rename detection is already activated by default in several cases like "git status" and "git merge", so activating diff.renames does not fundamentally change the situation. When the rename detection fails, it now fails consistently between "git diff" and "git status". This setting does not affect plumbing commands, hence well-written scripts will not be affected. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13format-patch: introduce format.outputDirectory configurationLibravatar Alexander Kuleshov1-0/+15
We can pass -o/--output-directory to the format-patch command to store patches in some place other than the working directory. This patch introduces format.outputDirectory configuration option for same purpose. The case of usage of this configuration option can be convenience to not pass every time -o/--output-directory if an user has pattern to store all patches in the /patches directory for example. The format.outputDirectory has lower priority than command line option, so if user will set format.outputDirectory and pass the command line option, a result will be stored in a directory that passed to command line option. Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Stephen P. Smith <ischis2@cox.net> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-15format-patch: check that header line has expected formatLibravatar brian m. carlson1-0/+7
The format of the "From " header line is very specific to allow utilities to detect Git-style patches. Add a test that the patches created are in the expected format. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-15format-patch: add an option to suppress commit hashLibravatar brian m. carlson1-0/+7
Oftentimes, patches created by git format-patch will be stored in version control or compared with diff. In these cases, two otherwise identical patches can have different commit hashes, leading to diff noise. Teach git format-patch a --zero-commit option that instead produces an all-zero hash to avoid this diff noise. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-24Merge branch 'jc/do-not-feed-tags-to-clear-commit-marks'Libravatar Junio C Hamano1-0/+8
"git format-patch --ignore-if-upstream A..B" did not like to be fed tags as boundary commits. * jc/do-not-feed-tags-to-clear-commit-marks: format-patch: do not feed tags to clear_commit_marks()
2015-06-01format-patch: do not feed tags to clear_commit_marks()Libravatar Junio C Hamano1-0/+8
"git format-patch --ignore-if-in-upstream A..B", when either A or B is a tag, failed miserably. This is because the code passes the tips it used for traversal to clear_commit_marks(), after running a temporary revision traversal to enumerate the commits on both branches to find if they have commits that make equivalent changes. The revision traversal machinery knows how to enumerate commits reachable starting from a tag, but clear_commit_marks() wants to take nothing but a commit. In the longer term, it might be a more correct fix to teach clear_commit_marks() to do the same "committish to commit" dereferencing that is done in the revision traversal machinery, but for now this fix should suffice. Reported-by: Bruce Korb <bruce.korb@gmail.com> Helped-by: Christian Couder <christian.couder@gmail.com> Helped-by: brian m. carlson <sandals@crustytoothpaste.net> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-16Merge branch 'jm/format-patch-mail-sig'Libravatar Junio C Hamano1-0/+61
* jm/format-patch-mail-sig: format-patch: add "--signature-file=<file>" option format-patch: make newline after signature conditional
2014-06-03Merge branch 'ep/shell-command-substitution'Libravatar Junio C Hamano1-5/+5
Adjust shell scripts to use $(cmd) instead of `cmd`. * ep/shell-command-substitution: (41 commits) t5000-tar-tree.sh: use the $( ... ) construct for command substitution t4204-patch-id.sh: use the $( ... ) construct for command substitution t4119-apply-config.sh: use the $( ... ) construct for command substitution t4116-apply-reverse.sh: use the $( ... ) construct for command substitution t4057-diff-combined-paths.sh: use the $( ... ) construct for command substitution t4038-diff-combined.sh: use the $( ... ) construct for command substitution t4036-format-patch-signer-mime.sh: use the $( ... ) construct for command substitution t4014-format-patch.sh: use the $( ... ) construct for command substitution t4013-diff-various.sh: use the $( ... ) construct for command substitution t4012-diff-binary.sh: use the $( ... ) construct for command substitution t4010-diff-pathspec.sh: use the $( ... ) construct for command substitution t4006-diff-mode.sh: use the $( ... ) construct for command substitution t3910-mac-os-precompose.sh: use the $( ... ) construct for command substitution t3905-stash-include-untracked.sh: use the $( ... ) construct for command substitution t1050-large.sh: use the $( ... ) construct for command substitution t1020-subdirectory.sh: use the $( ... ) construct for command substitution t1004-read-tree-m-u-wf.sh: use the $( ... ) construct for command substitution t1003-read-tree-prefix.sh: use the $( ... ) construct for command substitution t1002-read-tree-m-u-2way.sh: use the $( ... ) construct for command substitution t1001-read-tree-m-2way.sh: use the $( ... ) construct for command substitution ...
2014-05-27format-patch: add "--signature-file=<file>" optionLibravatar Jeremiah Mahler1-0/+61
Add an option to format-patch for reading a signature from a file. $ git format-patch -1 --signature-file=$HOME/.signature The config variable `format.signaturefile` can also be used to make this the default. $ git config format.signaturefile $HOME/.signature $ git format-patch -1 Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>