summaryrefslogtreecommitdiff
path: root/Documentation/git-format-patch.txt
AgeCommit message (Collapse)AuthorFilesLines
2016-04-26format-patch: introduce --base=auto optionLibravatar Xiaolong Ye1-0/+6
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/+54
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-01-26Merge branch 'ak/format-patch-odir-config'Libravatar Junio C Hamano1-1/+5
"git format-patch" learned to notice format.outputDirectory configuration variable. This allows "-o <dir>" option to be omitted on the command line if you always use the same directory in your workflow. * ak/format-patch-odir-config: format-patch: introduce format.outputDirectory configuration
2016-01-20Merge branch 'dw/signoff-doc'Libravatar Junio C Hamano1-0/+1
The documentation has been updated to hint the connection between the '--signoff' option and DCO. * dw/signoff-doc: Expand documentation describing --signoff
2016-01-13format-patch: introduce format.outputDirectory configurationLibravatar Alexander Kuleshov1-1/+5
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>
2016-01-05Expand documentation describing --signoffLibravatar David A. Wheeler1-0/+1
Modify various document (man page) files to explain in more detail what --signoff means. This was inspired by https://lwn.net/Articles/669976/ where paulj noted, "adding [the] '-s' argument to [a] git commit doesn't really mean you have even heard of the DCO...". Extending git's documentation will make it easier to argue that developers understood --signoff when they use it. Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-15format-patch: add an option to suppress commit hashLibravatar brian m. carlson1-0/+4
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-09-17Merge branch 'po/doc-branch-desc'Libravatar Junio C Hamano1-1/+1
The branch descriptions that are set with "git branch --edit-description" option were used in many places but they weren't clearly documented. * po/doc-branch-desc: doc: show usage of branch description
2015-09-14doc: show usage of branch descriptionLibravatar Philip Oakley1-1/+1
The branch description will be included in 'git format-patch --cover-letter' and in 'git pull-request' emails. It can also be used in the automatic merge message. Tell the reader. While here, clarify that the description may be a multi-line explanation of the purpose of the branch's patch series. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-24Merge branch 'fk/doc-format-patch-vn'Libravatar Junio C Hamano1-1/+1
Docfix. * fk/doc-format-patch-vn: doc: format-patch: fix typo
2015-06-10doc: format-patch: fix typoLibravatar Frans Klaver1-1/+1
reroll count documentation states that v<n> will be pretended to the filename. Judging by the examples that should have been 'prepended'. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-13*config.txt: stick to camelCase naming conventionLibravatar Nguyễn Thái Ngọc Duy1-2/+2
This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27format-patch: add "--signature-file=<file>" optionLibravatar Jeremiah Mahler1-0/+4
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>
2013-10-14format-patch doc: Thunderbird wraps lines unless mailnews.wraplength=0Libravatar Ramsay Jones1-1/+2
The Thunderbird section of the 'MUA-specific hints' contains three different approaches to setting up the mail client to leave patch emails unmolested. The second approach (configuration) has a step missing when configuring the composition window not to wrap. In particular, the "mailnews.wraplength" configuration variable needs to be set to zero. Update the documentation to add the missing setting. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-08-05log, format-patch: parsing uses OPT__QUIETLibravatar Stefan Beller1-0/+1
This patch allows users to use the short form -q on log and format-patch, which was non possible before. Also the documentation of format-patch mentions -q now. The documentation of log doesn't even talk about --quiet, so I'll leave that for more experienced git contributors. ;) It doesn't seem to change the default behavior, but in combination with --stat for example it suppresses the actual stats. however the only relevant code in log is if (quiet) rev->diffopt.output_format |= DIFF_FORMAT_NO_OUTPUT; Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-03teach format-patch to place other authors into in-body "From"Libravatar Jeff King1-0/+15
Format-patch generates emails with the "From" address set to the author of each patch. If you are going to send the emails, however, you would want to replace the author identity with yours (if they are not the same), and bump the author identity to an in-body header. Normally this is handled by git-send-email, which does the transformation before sending out the emails. However, some workflows may not use send-email (e.g., imap-send, or a custom script which feeds the mbox to a non-git MUA). They could each implement this feature themselves, but getting it right is non-trivial (one must canonicalize the identities by reversing any RFC2047 encoding or RFC822 quoting of the headers, which has caused many bugs in send-email over the years). This patch takes a different approach: it teaches format-patch a "--from" option which handles the ident check and in-body header while it is writing out the email. It's much simpler to do at this level (because we haven't done any quoting yet), and any workflow based on format-patch can easily turn it on. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07format-patch: add format.coverLetter configuration variableLibravatar Felipe Contreras1-2/+3
Also, add a new option: 'auto', so if there's more than one patch, the cover letter is generated, otherwise it's not. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-5/+5
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-11Merge branch 'jc/format-patch-reroll'Libravatar Junio C Hamano1-1/+10
Teach "format-patch" to prefix v4- to its output files for the fourth iteration of a patch series, to make it easier for the submitter to keep separate copies for iterations. * jc/format-patch-reroll: format-patch: give --reroll-count a short synonym -v format-patch: document and test --reroll-count format-patch: add --reroll-count=$N option get_patch_filename(): split into two functions get_patch_filename(): drop "just-numbers" hack get_patch_filename(): simplify function signature builtin/log.c: stop using global patch_suffix builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter() builtin/log.c: drop unused "numbered" parameter from make_cover_letter()
2013-01-03format-patch: give --reroll-count a short synonym -vLibravatar Junio C Hamano1-1/+2
Accept "-v" as a synonym to "--reroll-count", so that users can say "git format-patch -v4 master", instead of having to fully spell it out as "git format-patch --reroll-count=4 master". As I do not think of a reason why users would want to tell the command to be "verbose", I think this should be OK. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-02format-patch: document and test --reroll-countLibravatar Junio C Hamano1-1/+9
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-26Doc format-patch: clarify --notes use caseLibravatar Philip Oakley1-7/+6
Remove double negative, and include the repeat usage across versions of a patch series. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff King <peff@peff.net>
2012-10-19Documentation: decribe format-patch --notesLibravatar Junio C Hamano1-1/+14
Even though I coded this, I am not sure what use scenarios would benefit from this option, so the description is unnecessarily negative at this moment. People who do want to use this feature need to come up with a more plausible use case and replace it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-13Documentation: describe subject more preciselyLibravatar Jeremy White1-4/+7
The discussion of email subject throughout the documentation is misleading; it indicates that the first line will always become the subject. In fact, the subject is generally all lines up until the first full blank line. This patch refines that, and makes more use of the concept of a commit title, with the title being all text up to the first blank line. Signed-off-by: Jeremy White <jwhite@codeweavers.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-2/+2
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-29Document negated forms of format-patch --to --cc --add-headersLibravatar Thomas Rast1-1/+8
The negated forms introduced in c426003 (format-patch: add --no-cc, --no-to, and --no-add-headers, 2010-03-07) were not documented anywhere. Add them to the descriptions of the positive forms. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-04Merge branch 'jn/format-patch-doc'Libravatar Junio C Hamano1-0/+169
* jn/format-patch-doc: Documentation/format-patch: suggest Toggle Word Wrap add-on for Thunderbird Documentation: publicize hints for sending patches with GMail Documentation: publicize KMail hints for sending patches inline Documentation: hints for sending patches inline with Thunderbird Documentation: explain how to check for patch corruption
2011-05-04Merge branch 'jn/maint-format-patch-doc'Libravatar Junio C Hamano1-0/+58
* jn/maint-format-patch-doc: Documentation: describe the format of messages with inline patches
2011-04-19Documentation/format-patch: suggest Toggle Word Wrap add-on for ThunderbirdLibravatar Johannes Sixt1-4/+14
Of the (now) three methods to send unmangled patches using Thunderbird, this method is listed first because it provides a single-click on-demand option rather than a permanent change of configuration like the other two methods. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-15Documentation: publicize hints for sending patches with GMailLibravatar Jonathan Nieder1-0/+14
The hints in SubmittingPatches about stopping GMail from clobbering patches are widely useful both as examples of "git send-email" and "git imap-send" usage. Move the documentation to the appropriate places. While at it, don't encourage storing passwords in config files. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-15Documentation: publicize KMail hints for sending patches inlineLibravatar Jonathan Nieder1-0/+16
These hints are in git's private SubmittingPatches document but a wider audience might be interested. Move them to the "git format-patch" manpage. I'm not sure what gotchas these hints are meant to work around. They might be completely false. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-15Documentation: hints for sending patches inline with ThunderbirdLibravatar Jonathan Nieder1-0/+83
The standard reference for this information is the article "Plain text e-mail - Thunderbird#Completely_plain_email" at kb.mozillazine.org, but the hints hidden away in git's SubmittingPatches file are more complete. Move them to the "git format-patch" manual so they can be installed with git and read by a wide audience. While at it, make some tweaks: - update "Approach #1" so it might work with Thunderbird 3; - remove ancient version numbers from the descriptions of both approaches so current readers might have more reason to complain if they don't work. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-15Documentation: explain how to check for patch corruptionLibravatar Jonathan Nieder1-0/+46
SubmittingPatches has some excellent advice about how to check a patch for corruption before sending it off. Move it to the format-patch manual so it can be installed with git's documentation for use by people not necessarily interested in the git project's practices. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-15Merge v1.7.5-rc2 into jn/format-patch-docLibravatar Junio C Hamano1-9/+0
This is to sync with the recent updates in Documentation/SubmittingPatches and Documentation/format-patch.txt
2011-04-15Documentation: describe the format of messages with inline patchesLibravatar Jonathan Nieder1-0/+58
Add a DISCUSSION section to the "git format-patch" manual to encourage people to send patches in a form that can be applied by "git am" automatically. There are two such forms: 1. The default form in which most metadata goes in the mail header and the message body starts with the patch description; 2. The snipsnip form in which a message starts with pertinent discussion and ends with a patch after a "scissors" mark. The example requires QP encoding in the "Subject:" header intended for the mailer to give the reader a chance to reflect on that, rather than being startled by it later. By contrast, in-body "From:" and "Subject:" lines should be human-readable and not QP encoded. Inspired-by: Jim Meyering <jim@meyering.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Improved-by: Junio C Hamano <gitster@pobox.com> Improved-by: Drew Northup <drew.northup@maine.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-12format-patch: document --quiet optionLibravatar Carlos Martín Nieto1-1/+4
Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-9/+0
The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.
2010-10-13Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Better advice on using topic branches for kernel development Documentation: update implicit "--no-index" behavior in "git diff" Documentation: expand 'git diff' SEE ALSO section Documentation: diff can compare blobs Documentation: gitrevisions is in section 7 shell portability: no "export VAR=VAL" CodingGuidelines: reword parameter expansion section Documentation: update-index: -z applies also to --index-info Documentation: No argument of ALLOC_GROW should have side-effects
2010-10-13Documentation: gitrevisions is in section 7Libravatar Jonathan Nieder1-1/+1
Fix references to gitrevisions(1) in the manual pages and HTML documentation. In practice, this will not matter much unless someone tries to use a hard copy of the git reference manual. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29Merge branch 'rr/format-patch-count-without-merges'Libravatar Junio C Hamano1-1/+1
* rr/format-patch-count-without-merges: format-patch: Don't go over merge commits t4014-format-patch: Call test_tick before committing
2010-08-27format-patch: Don't go over merge commitsLibravatar Ramkumar Ramachandra1-1/+1
If the topmost three commits in a branch were merge commits, 'git format-patch -3' used to output nothing. Since Git can't prepare patches out of merge commits anyway, don't go over them in the first place. 'git format-patch -3' now prepares three patches from the topmost three commits without counting merge commits. Also add a corresponding test in t4014-format-patch and update documentation. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05Documentation: link to gitrevisions rather than git-rev-parseLibravatar Michael J Gruber1-1/+1
Currently, whenever we need documentation for revisions and ranges, we link to the git-rev-parse man page, i.e. a plumbing man page, which has this along with the documentation of all rev-parse modes. Link to the new gitrevisions man page instead in all cases except - when the actual git-rev-parse command is referred to or - in very technical context (git-send-pack). Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-16format-patch: Add a signature option (--signature)Libravatar Stephen Boyd1-0/+7
By default, git uses the version string as the signature for all patches output by format-patch. Many employers (mine included) require the use of a signature on all outgoing mails. In a format-patch | send-email workflow there isn't an easy way to modify the signature without breaking the pipe and manually replacing the version string with the signature required. Instead of doing all that work, add an option (--signature) and a config variable (format.signature) to replace the default git version signature when formatting patches. This does modify the original behavior of format-patch a bit. First off the version string is now placed in the cover letter by default. Secondly, once the configuration variable format.signature is added to the .config file there is no way to revert back to the default git version signature. Instead, specifying the --no-signature option will remove the signature from the patches entirely. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-06Add 'git format-patch --to=' option and 'format.to' configuration variable.Libravatar Steven Drake1-3/+8
Has the same functionality as the '--cc' option and 'format.cc' configuration variable but for the "To:" email header. Half of the code to support this was already there. With email the To: header usually more important than the Cc: header. [jc: tests are by Stephen Boyd] Signed-off-by: Steven Drake <sdrake@xnet.co.nz> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-2/+2
The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.
2009-11-10format-patch documentation: Fix formattingLibravatar Björn Gustavsson1-23/+23
Format git commands and options consistently using back quotes (i.e. a fixed font in the resulting HTML document). Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-22Improve doc for format-patch threading options.Libravatar Yann Dirson1-7/+15
This hopefully makes the relationship between threading options of format-patch and send-email easier to grasp. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-23git-format-patch.txt: general rewordings and cleanupsLibravatar Stephen Boyd1-19/+19
Clarify --no-binary description using some words from the original commit 37c22a4b (add --no-binary, 2008-05-9). Cleanup --suffix description. Add --thread style option to synopsis and reorganize it a bit. Clarify renaming patches example and the configuration paragraph. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-23Documentation: use lowercase for shallow and deep threadingLibravatar Stephen Boyd1-2/+2
Even when a sentence is started with 'shallow' or 'deep' use the lowercase version to maintain consistency. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-20Documentation: fix typos / spelling mistakesLibravatar Mike Ralphson1-1/+1
Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>