summaryrefslogtreecommitdiff
path: root/Documentation/git-send-email.txt
AgeCommit message (Collapse)Author
2016-07-13Merge branch 'mm/doc-tt'Junio C Hamano
More mark-up updates to typeset strings that are expected to literally typed by the end user in fixed-width font. * mm/doc-tt: doc: typeset HEAD and variants as literal CodingGuidelines: formatting HEAD in documentation doc: typeset long options with argument as literal doc: typeset '--' as literal doc: typeset long command-line options as literal doc: typeset short command-line options as literal Documentation/git-mv.txt: fix whitespace indentation
2016-06-28doc: typeset long command-line options as literalMatthieu Moy
Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-27Merge branch 'tr/doc-tt'Junio C Hamano
The documentation set has been updated so that literal commands, configuration variables and environment variables are consistently typeset in fixed-width font and bold in manpages. * tr/doc-tt: doc: change configuration variables format doc: more consistency in environment variables format doc: change environment variables format doc: clearer rule about formatting literals
2016-06-08doc: change configuration variables formatTom Russello
This change configuration variables that where in italic style to monospace font according to the guideline. It was obtained with grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \ sed -e 's/::$//' -e 's/\./\\\\./' | \ xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-02Documentation/git-send-email: fix typo in gmail 2FA sectionSZEDER Gábor
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-27Documentation: add instructions to help setup gmail 2FAMichael Rappazzo
For those who use two-factor authentication with gmail, git-send-email will not work unless it is setup with an app-specific password. The example for setting up git-send-email for use with gmail will now include information on generating and storing the app-specific password. Signed-off-by: Michael Rappazzo <rappazzo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-20sendemail: teach git-send-email to dump alias namesJacob Keller
Add an option "--dump-aliases" which changes the default behavior of git-send-email. This mode will simply read the alias files configured by sendemail.aliasesfile and sendemail.aliasfiletype and dump a list of all configured aliases, one per line. The intended use case for this option is the bash-completion script which will use it to autocomplete aliases on the options which take addresses. Add some tests for the new option using various alias file formats. A possible future extension to the alias dump format could be done by extending the --dump-aliases to take an optional argument defining the format to display. This has not been done in this patch as no user of this information has been identified. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2015-08-26Merge branch 'jv/send-email-selective-smtp-auth'Junio C Hamano
"git send-email" learned a new option --smtp-auth to limit the SMTP AUTH mechanisms to be used to a subset of what the system library supports. * jv/send-email-selective-smtp-auth: send-email: provide whitelist of SMTP AUTH mechanisms
2015-08-17send-email: provide whitelist of SMTP AUTH mechanismsJan Viktorin
When sending an e-mail, the client and server must agree on an authentication mechanism. Some servers (due to misconfiguration or a bug) deny valid credentials for certain mechanisms. In this patch, a new option --smtp-auth and configuration entry smtpAuth are introduced. If smtp_auth is defined, it works as a whitelist of allowed mechanisms for authentication selected from the ones supported by the installed SASL perl library. Signed-off-by: Jan Viktorin <viktorin@rehivetech.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'rl/send-email-aliases'Junio C Hamano
"git send-email" now performs alias-expansion on names that are given via --cccmd, etc. This round comes with a lot more enhanced e-mail address parser, which makes it a bit scary, but as long as it works as designed, it makes it wonderful ;-). * rl/send-email-aliases: send-email: suppress meaningless whitespaces in from field send-email: allow multiple emails using --cc, --to and --bcc send-email: consider quote as delimiter instead of character send-email: reduce dependencies impact on parse_address_line send-email: minor code refactoring send-email: allow use of aliases in the From field of --compose mode send-email: refactor address list process t9001-send-email: refactor header variable fields replacement send-email: allow aliases in patch header and command script outputs t9001-send-email: move script creation in a setup test
2015-07-07send-email: allow multiple emails using --cc, --to and --bccRemi Lespinet
Accept a list of emails separated by commas in flags --cc, --to and --bcc. Multiple addresses can already be given by using these options multiple times, but it is more convenient to allow cutting-and-pasting a list of addresses from the header of an existing e-mail message, which already lists them as comma-separated list, as a value to a single parameter. The following format can now be used: $ git send-email --to='Jane <jdoe@example.com>, mike@example.com' Remove the limitation imposed by 79ee555b (Check and document the options to prevent mistakes, 2006-06-21) which rejected every argument with comma in --cc, --to and --bcc. Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr> Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01send-email: implement sendmail aliases line continuation supportEric Sunshine
Logical lines in sendmail aliases files can be spread over multiple physical lines[1]. A line beginning with whitespace is folded into the preceding line. A line ending with '\' consumes the following line. [1]: https://www.freebsd.org/cgi/man.cgi?query=aliases&sektion=5 Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01send-email: further document missing sendmail aliases functionalityEric Sunshine
Sendmail aliases[1] supports expansion to a file ("/path/name") or pipe ("|command"), as well as file inclusion (":include: /path/name"), however, our implementation does not support such functionality. [1]: https://www.freebsd.org/cgi/man.cgi?query=aliases&sektion=5 Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-27send-email: add sendmail email aliases formatAllen Hubbe
Teach send-email to read aliases in the sendmail aliases format, i.e. <alias>: <address|alias>[, <address|alias>...] Examples: alice: Alice W Land <awol@example.com> bob: Robert Bobbyton <bob@example.com> # this is a comment # this is also a comment chloe: chloe@example.com abgroup: alice, bob bcgrp: bob, chloe, Other <o@example.com> - Quoted aliases and quoted addresses are not supported. - Line continuations are not supported. Warnings are printed for explicitly unsupported constructs, and any other lines that are not matched by the parser. Signed-off-by: Allen Hubbe <allenbh@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-14*config.txt: stick to camelCase naming conventionNguyễn Thái Ngọc Duy
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>
2015-01-14Merge branch 'aw/doc-smtp-ssl-cert-path'Junio C Hamano
A long overdue documentation update to match an age-old code update. * aw/doc-smtp-ssl-cert-path: correct smtp-ssl-cert-path description
2015-01-07Merge branch 'lh/send-email-hide-x-mailer'Junio C Hamano
"git send-email" normally identifies itself via X-Mailer: header in the message it sends out. A new command line flag allows the user to squelch the header. * lh/send-email-hide-x-mailer: test/send-email: --[no-]xmailer tests send-email: add --[no-]xmailer option
2015-01-07correct smtp-ssl-cert-path descriptionAdam Williamson
The git-send-email documentation was never updated to reflect the change made in 01645b74 to use the SSL library's default CA trust store rather than /etc/ssl/certs as a hardcoded default CApath. This corrects that, and also tweaks the rest of the text a bit to explain more accurately what is required for a valid CApath / CAfile. Signed-off-by: Adam Williamson <awilliam@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-15send-email: add --[no-]xmailer optionLuis Henriques
Add --[no-]xmailer that allows a user to disable adding the 'X-Mailer:' header to the email being sent. Signed-off-by: Luis Henriques <henrix@camandro.org> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-send-email: add --transfer-encoding optionPaolo Bonzini
The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-20Merge branch 'mt/send-email-cover-to-cc'Junio C Hamano
* mt/send-email-cover-to-cc: t9001: avoid non-portable '\n' with sed test/send-email: to-cover, cc-cover tests git-send-email: two new options: to-cover, cc-cover
2014-05-21Documentation: use "command-line" when used as a compound adjective, and fix ↵Jason St. John
other minor grammatical issues Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-29git-send-email: two new options: to-cover, cc-coverMichael S. Tsirkin
Allow extracting To/Cc addresses from the first patch (typically the cover letter), and use them as To/Cc addresses of the remainder of the series. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18send-email: be explicit with SSL certificate verificationRamkumar Ramachandra
When initiating an SSL connection without explicitly specifying the SSL certificate verification mode, Net::SMTP::SSL defaults to no verification, but recent versions of the module gives a warning against this use of the default. Enable certificate verification by default, using /etc/ssl/certs as the default path for certificates of certificate authorities. This path can be overriden by the --smtp-ssl-cert-path command line option and the sendemail.smtpSSLCertPath configuration variable. Passing an empty string as the path for CA certificates path disables the SSL certificate verification explicitly, which does not trigger the warning from recent versions of Net::SMTP::SSL. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Helped-by: Brian M. Carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07send-email: make annotate configurableFelipe Contreras
Some people always do --annotate, lets not force them to always type that. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-27git-send-email: use git credential to obtain passwordMichal Nazarewicz
If smtp_user is provided but smtp_pass is not, instead of prompting for password, make git-send-email use git credential command instead. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: avoid poor-man's small caps GITThomas Ackermann
In the earlier days, we used to spell the name of the system as GIT, to simulate as if it were typeset with capital G and IT in small caps. Later we stopped doing so at around 1.6.5 days. Let's stop doing so throughout the documentation. The name to refer to the whole system (and the concept it embodies) is "Git"; the command end-users type is "git". And document this in the coding guideline. Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-10git-send-email: introduce compose-encodingKrzysztof Mazur
The introduction email (--compose option) have encoding hardcoded to UTF-8, but invoked editor may not use UTF-8 encoding. The encoding used by patches can be changed by the "8bit-encoding" option, but this option does not have effect on introduction email and equivalent for introduction email is missing. Added compose-encoding command line option and sendemail.composeencoding configuration option specify encoding of introduction email. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-27send-email: document the --smtp-debug optionZbigniew Jędrzejewski-Szmek
The option was already shown in -h output, so it should be documented in the man page. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Suggested-by: David A. Greene <greened@obbligato.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-06Documentation: use [verse] for SYNOPSIS sectionsMartin von Zweigbergk
The SYNOPSIS sections of most commands that span several lines already use [verse] to retain line breaks. Most commands that don't span several lines seem not to use [verse]. In the HTML output, [verse] does not only preserve line breaks, but also makes the section indented, which causes a slight inconsistency between commands that use [verse] and those that don't. Use [verse] in all SYNOPSIS sections for consistency. Also remove the blank lines from git-fetch.txt and git-rebase.txt to align with the other man pages. In the case of git-rebase.txt, which already uses [verse], the blank line makes the [verse] not apply to the last line, so removing the blank line also makes the formatting within the document more consistent. While at it, add single quotes to 'git cvsimport' for consistency with other commands. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-15Documentation: publicize hints for sending patches with GMailJonathan Nieder
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-03-11doc: drop author/documentation sections from most pagesJeff King
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-12-11Merge branch 'maint'Junio C Hamano
2010-12-10Add --force to git-send-email documentationAlejandro R. Sedeño
Signed-off-by: Alejandro R. Sedeño <asedeno@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-12git-send-email.perl: make initial In-Reply-To apply only to first emailAntonio Ospite
When an initial --in-reply-to is supplied, make it apply only to the first message; --[no-]chain-reply-to setting are honored by second and subsequent messages; this is also how the git-format-patch option with the same name behaves. Moreover, when $initial_reply_to is asked to the user interactively it is asked as the "Message-ID to be used as In-Reply-To for the _first_ email", this makes the user think that the second and subsequent patches are not using it but are considered as replies to the first message or chained according to the --[no-]chain-reply setting. Look at the v2 series in the illustration to see what the new behavior ensures: (before the patch) | (after the patch) [PATCH 0/2] Here is what I did... | [PATCH 0/2] Here is what I did... [PATCH 1/2] Clean up and tests | [PATCH 1/2] Clean up and tests [PATCH 2/2] Implementation | [PATCH 2/2] Implementation [PATCH v2 0/3] Here is a reroll | [PATCH v2 0/3] Here is a reroll [PATCH v2 1/3] Clean up | [PATCH v2 1/3] Clean up [PATCH v2 2/3] New tests | [PATCH v2 2/3] New tests [PATCH v2 3/3] Implementation | [PATCH v2 3/3] Implementation This is the typical behaviour we want when we send a series with cover letter in reply to some discussion, the new patch series should appear as a separate subtree in the discussion. Also update the documentation on --in-reply-to to describe the new behavior. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-27Merge branch 'jp/send-email-to-cmd'Junio C Hamano
* jp/send-email-to-cmd: git-send-email.perl: Add --to-cmd Conflicts: git-send-email.perl
2010-09-27git-send-email.perl: Add --to-cmdJoe Perches
Add the ability to use a command line --to-cmd=cmd to create the list of "To:" addresses. Used a shared routine for --cc-cmd and --to-cmd. Did not use IPC::Open2, leaving that for Ævar if ever he decides to fix the other bugs he might find. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07New send-email option smtpserveroption.Pascal Obry
The new command line parameter --smtp-server-option or default configuration sendemail.smtpserveroption can be used to pass specific options to the SMTP server. Update the documentation accordingly. Signed-off-by: Pascal Obry <pascal@obry.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27Merge branch 'tr/send-email-8bit'Junio C Hamano
* tr/send-email-8bit: send-email: ask about and declare 8bit mails
2010-06-18send-email: ask about and declare 8bit mailsThomas Rast
git-send-email passes on an 8bit mail as-is even if it does not declare a content-type. Because the user can edit email between format-patch and send-email, such invalid mails are unfortunately not very hard to come by. Make git-send-email stop and ask about the encoding to use if it encounters any such mail. Also provide a configuration setting to permanently configure an encoding. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-09Merge branch 'bg/send-email-smtpdomain'Junio C Hamano
* bg/send-email-smtpdomain: send-email: Cleanup smtp-domain and add config Document send-email --smtp-domain send-email: Don't use FQDNs without a '.' send-email: Cleanup { style
2010-05-04Documentation/git-send-email: Add "Use gmail as the smtp server"Ping Yin
Signed-off-by: Ping Yin <pkufranky@gmail.com> Acked by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-10send-email: Cleanup smtp-domain and add configBrian Gernhardt
The way the code stored --smtp-domain was unlike its handling of other similar options. Bring it in line with the others by: - Renaming $mail_domain to $smtp_domain to match the command line option. Also move its declaration from near the top of the file to near other option variables. - Removing $mail_domain_default. The variable was used once and only served to move the default away from where it gets used. - Adding a sendemail.smtpdomain config option. smtp-domain was the only SMTP configuration option that couldn't be set in the user's .gitconfig. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-10Document send-email --smtp-domainBrian Gernhardt
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-26Merge branch 'jc/1.7.0-send-email-no-thread-default'Junio C Hamano
* jc/1.7.0-send-email-no-thread-default: send-email: make --no-chain-reply-to the default Conflicts: git-send-email.perl
2009-11-30Merge branch 'fc/send-email-envelope'Junio C Hamano
2009-11-28send-email: automatic envelope senderFelipe Contreras
This adds the option to specify the envelope sender as "auto" which would pick the 'from' address. This is good because now we can specify the address only in one place in $HOME/.gitconfig and change it easily. [jc: added tests] Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"Jonathan Nieder
Use the new "git var GIT_EDITOR" feature to decide what editor to use, instead of duplicating its logic elsewhere. This should make the behavior of commands in edge cases (e.g., editor names with spaces) a little more consistent. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-23send-email: make --no-chain-reply-to the defaultJunio C Hamano
In http://article.gmane.org/gmane.comp.version-control.git/109790 I threatened to announce a change to the default threading style used by send-email to no-chain-reply-to (i.e. the second and subsequent messages will all be replies to the first one), unless nobody objected, in 1.6.3. Nobody objected, as far as I can dig the list archive. But when nothing happened in 1.6.3 nor 1.6.4, nobody from the camp who complained loudly that led to the message did not complain either. So I am guessing that after all nobody cares about this. But 1.7.0 is a good time to change this, and as I said in the message, I personally think it is a good change, so here it is. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-31Documentation: git-send-email: correct statement about standard portsWesley J. Landaker
The current documentation states that servers typically listen on port 465 and calls this "ssmtp". While it's true that many mail servers use port 465 for SSL smtp, this is non-standard, and hails from the days before smtp and submission TLS support, that arrived in RFC2487 and RFC3207. Port 465 is actually assigned by IANA for unrelated purposes, and is mostly still used by mail servers today only to support Outlook Express. In any case, this patch helps the documentation better reflect both standards and reality, while still helpfully mentioning ports numbers that a user may wish to specify. Signed-off-by: Wesley J. Landaker <wjl@icecavern.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>