summaryrefslogtreecommitdiff
path: root/Documentation/git-push.txt
AgeCommit message (Collapse)AuthorFilesLines
2016-02-26Merge branch 'mm/push-simple-doc'Libravatar Junio C Hamano1-0/+7
The documentation did not clearly state that the 'simple' mode is now the default for "git push" when push.default configuration is not set. * mm/push-simple-doc: Documentation/git-push: document that 'simple' is the default
2016-02-24Merge branch 'ew/force-ipv4'Libravatar Junio C Hamano1-0/+7
"git fetch" and friends that make network connections can now be told to only use ipv4 (or ipv6). * ew/force-ipv4: connect & http: support -4 and -6 switches for remote operations
2016-02-23Documentation/git-push: document that 'simple' is the defaultLibravatar Matthieu Moy1-0/+7
The default behavior is well documented already in git-config(1), but git-push(1) itself did not mention it at all. For users willing to learn how "git push" works but not how to configure it, this makes the documentation cumbersome to read. Make the git-push(1) page self-contained by adding a short summary of what 'push.default=simple' does, early in the page. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-12connect & http: support -4 and -6 switches for remote operationsLibravatar Eric Wong1-0/+7
Sometimes it is necessary to force IPv4-only or IPv6-only operation on networks where name lookups may return a non-routable address and stall remote operations. The ssh(1) command has an equivalent switches which we may pass when we run them. There may be old ssh(1) implementations out there which do not support these switches; they should report the appropriate error in that case. rsync support is untouched for now since it is deprecated and scheduled to be removed. Signed-off-by: Eric Wong <normalperson@yhbt.net> Reviewed-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12Merge branch 'ps/push-delete-option'Libravatar Junio C Hamano1-1/+1
"branch --delete" has "branch -d" but "push --delete" does not. * ps/push-delete-option: push: add '-d' as shorthand for '--delete' push: add '--delete' flag to synopsis
2015-12-16push: add '-d' as shorthand for '--delete'Libravatar Patrick Steinhardt1-1/+1
"git push" takes "--delete" but does not take a short form "-d", unlike "git branch" which does take both. Bring consistency between them. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-14push: add '--delete' flag to synopsisLibravatar Patrick Steinhardt1-1/+1
The delete flag is not mentioned in the synopsis of `git-push`. Add the flag to make it more discoverable. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-20push: add recurseSubmodules config optionLibravatar Mike Crowe1-10/+14
The --recurse-submodules command line parameter has existed for some time but it has no config file equivalent. Following the style of the corresponding parameter for git fetch, let's invent push.recurseSubmodules to provide a default for this parameter. This also requires the addition of --recurse-submodules=no to allow the configuration to be overridden on the command line when required. The most straightforward way to implement this appears to be to make push use code in submodule-config in a similar way to fetch. Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Jeff King <peff@peff.net>
2015-10-29Merge branch 'jc/em-dash-in-doc'Libravatar Junio C Hamano1-1/+1
AsciiDoc markup fixes. * jc/em-dash-in-doc: Documentation: AsciiDoc spells em-dash as double-dashes, not triple
2015-10-22Documentation: AsciiDoc spells em-dash as double-dashes, not tripleLibravatar Junio C Hamano1-1/+1
Again, we do not usually process release notes with AsciiDoc, but it is better to be consistent. This incidentally reveals breakages left by an ancient 5e00439f (Documentation: build html for all files in technical and howto, 2012-10-23). The index-format documentation was originally written to be read as straight text without formatting and when the commit forced everything in Documentation/ to go through AsciiDoc, it did not do any adjustment--hence the double-dashes will be seen in the resulting text that is rendered as preformatted fixed-width without converted into em-dashes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-19push: support signing pushes iff the server supports itLibravatar Dave Borowitz1-7/+10
Add a new flag --sign=true (or --sign=false), which means the same thing as the original --signed (or --no-signed). Give it a third value --sign=if-asked to tell push and send-pack to send a push certificate if and only if the server advertised a push cert nonce. If not, warn the user that their push may not be as secure as they thought. Signed-off-by: Dave Borowitz <dborowitz@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-19Documentation/git-push.txt: document when --signed may failLibravatar Dave Borowitz1-1/+3
Like --atomic, --signed will fail if the server does not advertise the necessary capability. In addition, it requires gpg on the client side. Signed-off-by: Dave Borowitz <dborowitz@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-05Merge branch 'jk/asciidoc-markup-fix' into maintLibravatar Junio C Hamano1-2/+2
Various documentation mark-up fixes to make the output more consistent in general and also make AsciiDoctor (an alternative formatter) happier. * jk/asciidoc-markup-fix: doc: convert AsciiDoc {?foo} to ifdef::foo[] doc: put example URLs and emails inside literal backticks doc: drop backslash quoting of some curly braces doc: convert \--option to --option doc/add: reformat `--edit` option doc: fix length of underlined section-title doc: fix hanging "+"-continuation doc: fix unquoted use of "{type}" doc: fix misrendering due to `single quote'
2015-05-12doc: convert \--option to --optionLibravatar Jeff King1-2/+2
Older versions of AsciiDoc would convert the "--" in "--option" into an emdash. According to 565e135 (Documentation: quote double-dash for AsciiDoc, 2011-06-29), this is fixed in AsciiDoc 8.3.0. According to bf17126, we don't support anything older than 8.4.1 anyway, so we no longer need to worry about quoting. Even though this does not change the output at all, there are a few good reasons to drop the quoting: 1. It makes the source prettier to read. 2. We don't quote consistently, which may be confusing when reading the source. 3. Asciidoctor does not like the quoting, and renders a literal backslash. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-31Merge branch 'ph/push-doc-cas' into maintLibravatar Junio C Hamano1-8/+6
* ph/push-doc-cas: git-push.txt: clean up force-with-lease wording
2015-03-28Merge branch 'ph/push-doc-cas'Libravatar Junio C Hamano1-8/+6
* ph/push-doc-cas: git-push.txt: clean up force-with-lease wording
2015-03-26git-push.txt: clean up force-with-lease wordingLibravatar Phil Hord1-8/+6
The help text for the --force-with-lease option to git-push does not parse cleanly. Clean up the wording and syntax to be more sensible. Also remove redundant information in the "--force-with-lease alone" description. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-23Merge branch 'jk/push-config'Libravatar Junio C Hamano1-1/+4
Restructure "git push" codepath to make it easier to add new configuration bits and then add push.followTags configuration that turns --follow-tags option on by default. * jk/push-config: push: allow --follow-tags to be set by config push.followTags cmd_push: pass "flags" pointer to config callback cmd_push: set "atomic" bit directly git_push_config: drop cargo-culted wt_status pointer
2015-03-14push: allow --follow-tags to be set by config push.followTagsLibravatar Dave Olszewski1-1/+4
Signed-off-by: Dave Olszewski <cxreg@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-24Merge branch 'mg/push-repo-option-doc' into maintLibravatar Junio C Hamano1-16/+2
The "git push" documentation made the "--repo=<there>" option easily misunderstood. * mg/push-repo-option-doc: git-push.txt: document the behavior of --repo
2015-02-17Merge branch 'mg/push-repo-option-doc'Libravatar Junio C Hamano1-16/+2
The "git push" documentation made the "--repo=<there>" option easily misunderstood. * mg/push-repo-option-doc: git-push.txt: document the behavior of --repo
2015-02-11Merge branch 'sb/atomic-push'Libravatar Junio C Hamano1-1/+6
"git push" has been taught a "--atomic" option that makes push to update more than one ref an "all-or-none" affair. * sb/atomic-push: Document receive.advertiseatomic t5543-atomic-push.sh: add basic tests for atomic pushes push.c: add an --atomic argument send-pack.c: add --atomic command line argument send-pack: rename ref_update_to_be_sent to check_to_send_update receive-pack.c: negotiate atomic push support receive-pack.c: add execute_commands_atomic function receive-pack.c: move transaction handling in a central place receive-pack.c: move iterating over all commands outside execute_commands receive-pack.c: die instead of error in case of possible future bug receive-pack.c: shorten the execute_commands loop over all commands
2015-01-28git-push.txt: document the behavior of --repoLibravatar Michael J Gruber1-16/+2
As per the code, the --repo <repo> option is equivalent to the <repo> argument to 'git push', but somehow it was documented as something that is more than that. [It exists for historical reasons, back from the time when options had to come before arguments.] Say so. [But not that.] Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-07push.c: add an --atomic argumentLibravatar Ronnie Sahlberg1-1/+6
Add a command line argument to the git push command to request atomic pushes. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-22Merge branch 'po/everyday-doc' into maintLibravatar Junio C Hamano1-1/+1
"Everyday" document had a broken link. * po/everyday-doc: Documentation: change "gitlink" typo in git-push
2014-12-12Merge branch 'po/everyday-doc'Libravatar Junio C Hamano1-1/+1
* po/everyday-doc: Documentation: change "gitlink" typo in git-push
2014-11-17Documentation: change "gitlink" typo in git-pushLibravatar brian m. carlson1-1/+1
The git-push manual page used "gitlink" in one place instead of "linkgit". Fix this so the link renders correctly. Noticed-by: Dan Allen <dan.j.allen@gmail.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16Merge branch 'po/everyday-doc'Libravatar Junio C Hamano1-1/+1
"git help everyday" to show the Everyday Git document. * po/everyday-doc: doc: add 'everyday' to 'git help' doc: Makefile regularise OBSOLETE_HTML list building doc: modernise everyday.txt wording and format in man page style
2014-10-10doc: add 'everyday' to 'git help'Libravatar Philip Oakley1-1/+1
The "Everyday GIT With 20 Commands Or So" is not accessible via the Git help system. Move everyday.txt to giteveryday.txt so that "git help everyday" works, and create a new placeholder file everyday.html to refer people who follow existing URLs to the updated location. giteveryday.txt now formats well with AsciiDoc as a man page and refreshed content to a more command modern style. Add 'everyday' to the help --guides list and update git(1) and 5 other links to giteveryday. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-08Merge branch 'jc/push-cert'Libravatar Junio C Hamano1-1/+8
Allow "git push" request to be signed, so that it can be verified and audited, using the GPG signature of the person who pushed, that the tips of branches at a public repository really point the commits the pusher wanted to, without having to "trust" the server. * jc/push-cert: (24 commits) receive-pack::hmac_sha1(): copy the entire SHA-1 hash out signed push: allow stale nonce in stateless mode signed push: teach smart-HTTP to pass "git push --signed" around signed push: fortify against replay attacks signed push: add "pushee" header to push certificate signed push: remove duplicated protocol info send-pack: send feature request on push-cert packet receive-pack: GPG-validate push certificates push: the beginning of "git push --signed" pack-protocol doc: typofix for PKT-LINE gpg-interface: move parse_signature() to where it should be gpg-interface: move parse_gpg_output() to where it should be send-pack: clarify that cmds_sent is a boolean send-pack: refactor inspecting and resetting status and sending commands send-pack: rename "new_refs" to "need_pack_data" receive-pack: factor out capability string generation send-pack: factor out capability string generation send-pack: always send capabilities send-pack: refactor decision to send update per ref send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher ...
2014-09-15push: the beginning of "git push --signed"Libravatar Junio C Hamano1-1/+8
While signed tags and commits assert that the objects thusly signed came from you, who signed these objects, there is not a good way to assert that you wanted to have a particular object at the tip of a particular branch. My signing v2.0.1 tag only means I want to call the version v2.0.1, and it does not mean I want to push it out to my 'master' branch---it is likely that I only want it in 'maint', so the signature on the object alone is insufficient. The only assurance to you that 'maint' points at what I wanted to place there comes from your trust on the hosting site and my authentication with it, which cannot easily audited later. Introduce a mechanism that allows you to sign a "push certificate" (for the lack of better name) every time you push, asserting that what object you are pushing to update which ref that used to point at what other object. Think of it as a cryptographic protection for ref updates, similar to signed tags/commits but working on an orthogonal axis. The basic flow based on this mechanism goes like this: 1. You push out your work with "git push --signed". 2. The sending side learns where the remote refs are as usual, together with what protocol extension the receiving end supports. If the receiving end does not advertise the protocol extension "push-cert", an attempt to "git push --signed" fails. Otherwise, a text file, that looks like the following, is prepared in core: certificate version 0.1 pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700 7339ca65... 21580ecb... refs/heads/master 3793ac56... 12850bec... refs/heads/next The file begins with a few header lines, which may grow as we gain more experience. The 'pusher' header records the name of the signer (the value of user.signingkey configuration variable, falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the certificate generation. After the header, a blank line follows, followed by a copy of the protocol message lines. Each line shows the old and the new object name at the tip of the ref this push tries to update, in the way identical to how the underlying "git push" protocol exchange tells the ref updates to the receiving end (by recording the "old" object name, the push certificate also protects against replaying). It is expected that new command packet types other than the old-new-refname kind will be included in push certificate in the same way as would appear in the plain vanilla command packets in unsigned pushes. The user then is asked to sign this push certificate using GPG, formatted in a way similar to how signed tag objects are signed, and the result is sent to the other side (i.e. receive-pack). In the protocol exchange, this step comes immediately before the sender tells what the result of the push should be, which in turn comes before it sends the pack data. 3. When the receiving end sees a push certificate, the certificate is written out as a blob. The pre-receive hook can learn about the certificate by checking GIT_PUSH_CERT environment variable, which, if present, tells the object name of this blob, and make the decision to allow or reject this push. Additionally, the post-receive hook can also look at the certificate, which may be a good place to log all the received certificates for later audits. Because a push certificate carry the same information as the usual command packets in the protocol exchange, we can omit the latter when a push certificate is in use and reduce the protocol overhead. This however is not included in this patch to make it easier to review (in other words, the series at this step should never be released without the remainder of the series, as it implements an interim protocol that will be incompatible with the final one). As such, the documentation update for the protocol is left out of this step. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-04Merge branch 'tf/maint-doc-push'Libravatar Junio C Hamano1-1/+1
* tf/maint-doc-push: git-push: fix link in man page
2014-07-31git-push: fix link in man pageLibravatar Tony Finch1-1/+1
Signed-off-by: Tony Finch <dot@dotat.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-08Merge branch 'jl/nor-or-nand-and'Libravatar Junio C Hamano1-1/+1
Eradicate mistaken use of "nor" (that is, essentially "nor" used not in "neither A nor B" ;-)) from in-code comments, command output strings, and documentations. * jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"
2014-03-31Documentation: fix misuses of "nor"Libravatar Justin Lebar1-1/+1
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-07Merge branch 'jc/push-2.0-default-to-simple'Libravatar Junio C Hamano1-4/+6
Finally update the "git push" default behaviour to "simple".
2013-12-04push: use remote.$name.push as a refmapLibravatar Junio C Hamano1-2/+7
Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-17Merge branch 'rh/ishes-doc'Libravatar Junio C Hamano1-1/+1
We liberally use "committish" and "commit-ish" (and "treeish" and "tree-ish"); as these are non-words, let's unify these terms to their dashed form. More importantly, clarify the documentation on object peeling using these terms. * rh/ishes-doc: glossary: fix and clarify the definition of 'ref' revisions.txt: fix and clarify <rev>^{<type>} glossary: more precise definition of tree-ish (a.k.a. treeish) use 'commit-ish' instead of 'committish' use 'tree-ish' instead of 'treeish' glossary: define commit-ish (a.k.a. committish) glossary: mention 'treeish' as an alternative to 'tree-ish'
2013-09-04use 'commit-ish' instead of 'committish'Libravatar Richard Hansen1-1/+1
Replace 'committish' in documentation and comments with 'commit-ish' to match gitglossary(7) and to be consistent with 'tree-ish'. The only remaining instances of 'committish' are: * variable, function, and macro names * "(also committish)" in the definition of commit-ish in gitglossary[7] Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22remote.c: add command line option parser for "--force-with-lease"Libravatar Junio C Hamano1-11/+66
Update "git push" and "git send-pack" to parse this commnd line option. The intended sematics is: * "--force-with-lease" alone, without specifying the details, will protect _all_ remote refs that are going to be updated by requiring their current value to be the same as some reasonable default, unless otherwise specified; * "--force-with-lease=refname", without specifying the expected value, will protect that refname, if it is going to be updated, by requiring its current value to be the same as some reasonable default. * "--force-with-lease=refname:value" will protect that refname, if it is going to be updated, by requiring its current value to be the same as the specified value; and * "--no-force-with-lease" will cancel all the previous --force-with-lease on the command line. For now, "some reasonable default" is tentatively defined as "the value of the remote-tracking branch we have for the ref of the remote being updated", and it is an error if we do not have such a remote-tracking branch. But this is known to be fragile, its use is not yet recommended, and hopefully we will find more reasonable default as we gain experience with this feature. The manual marks the feature as experimental unless the expected value is specified explicitly for this reason. Because the command line options are parsed _before_ we know which remote we are pushing to, there needs further processing to the parsed data after we instantiate the transport object to: * expand "refname" given by the user to a full refname to be matched with the list of "struct ref" used in match_push_refs() and set_ref_status_for_push(); and * learning the actual local ref that is the remote-tracking branch for the specified remote ref. Further, some processing need to be deferred until we find the set of remote refs and match_push_refs() returns in order to find the ones that need to be checked after explicit ones have been processed for "--force-with-lease" (no specific details). These post-processing will be the topic of the next patch. This option was originally called "cas" (for "compare and swap"), the name which nobody liked because it was too technical. The second attempt called it "lockref" (because it is conceptually like pushing after taking a lock) but the word "lock" was hated because it implied that it may reject push by others, which is not the way this option works. This round calls it "force-with-lease". You assume you took the lease on the ref when you fetched to decide what the rebased history should be, and you can push back only if the lease has not been broken. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26Merge branch 'mm/push-force-is-dangerous'Libravatar Junio C Hamano1-0/+9
* mm/push-force-is-dangerous: Documentation/git-push.txt: explain better cases where --force is dangerous
2013-06-18push: switch default from "matching" to "simple"Libravatar Junio C Hamano1-11/+14
We promised to change the behaviour of lazy "git push [there]" that does not say what to push on the command line from "matching" to "simple" in Git 2.0. This finally flips that bit. Helped-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-18Documentation/git-push.txt: explain better cases where --force is dangerousLibravatar Matthieu Moy1-0/+9
The behavior of "git push --force" is rather clear when it updates only one remote ref, but running it when pushing several branches can really be dangerous. Warn the users a bit more and give them the alternative to push only one branch. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-05Merge branch 'tr/push-no-verify-doc'Libravatar Junio C Hamano1-1/+6
"git push --[no-]verify" was not documented. * tr/push-no-verify-doc: Document push --no-verify
2013-05-23Document push --no-verifyLibravatar Thomas Rast1-1/+6
ec55559 (push: Add support for pre-push hooks, 2013-01-13) forgot to add a note to git-push(1) about the new --no-verify option. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-17documentation: trivial style cleanupsLibravatar Felipe Contreras1-2/+1
White-spaces, missing braces, standardize --[no-]foo. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-26Merge branch 'jc/maint-push-refspec-default-doc' into maintLibravatar Junio C Hamano1-9/+14
* jc/maint-push-refspec-default-doc: Documentation/git-push: clarify the description of defaults
2013-03-25Merge branch 'jc/push-follow-tag'Libravatar Junio C Hamano1-1/+7
The new "--follow-tags" option tells "git push" to push relevant annotated tags when pushing branches out. * jc/push-follow-tag: push: --follow-tags commit.c: use clear_commit_marks_many() in in_merge_bases_many() commit.c: add in_merge_bases_many() commit.c: add clear_commit_marks_many()
2013-03-21Merge branch 'jc/maint-push-refspec-default-doc'Libravatar Junio C Hamano1-9/+14
Clarify in the documentation "what" gets pushed to "where" when the command line to "git push" does not say these explicitly. * jc/maint-push-refspec-default-doc: Documentation/git-push: clarify the description of defaults
2013-03-08Documentation/git-push: clarify the description of defaultsLibravatar Junio C Hamano1-9/+14
We describe what gets pushed by default when the command line does not give any <refspec> under the bullet point of <refspec>. It is a bit unfriendly to expect users to read on <refspec> when they are not giving any in the first place. "What gets pushed" is determined by taking many factors (<refspec> argument being only one of them) into account, and is a property of the entire command, not an individual argument. Also we do not describe "Where the push goes" when the command line does not say. Give the description on "what gets pushed to where" upfront before explaining individual arguments and options. Also update the description of <refspec> to say what it is, what it is used for, before explaining what shape it takes. Signed-off-by: Junio C Hamano <gitster@pobox.com>