summaryrefslogtreecommitdiff
path: root/Documentation/git-send-pack.txt
AgeCommit message (Collapse)AuthorFilesLines
2021-09-12send-pack: properly use parse_options() API for usage stringLibravatar Ævar Arnfjörð Bjarmason1-2/+2
When "send-pack" was changed to use the parse_options() API in 068c77a5189 (builtin/send-pack.c: use parse_options API, 2015-08-19) it was made to use one very long line, instead it should split them up with newlines. Furthermore we were including an inline explanation that you couldn't combine "--all" and "<ref>", but unlike in the "blame" case this was not preceded by an empty string. Let's instead show that --all and <ref> can't be combined in the the usual language of the usage syntax instead. We can make it clear that one of the two options "--foo" and "--bar" is mandatory, but that the two are mutually exclusive by referring to them as "( --foo | --bar )". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02doc: keep first level section header in upper caseLibravatar Nguyễn Thái Ngọc Duy1-1/+1
When formatted as a man page, 1st section header is always in upper case even if we write it otherwise. Make all 1st section headers uppercase to keep it close to the final output. This does affect html since case is kept there, but I still think it's a good idea to maintain a consistent style for 1st section headers. Some sections perhaps should become second sections instead, where case is kept, and for better organization. I will update if anyone has suggestions about this. While at there I also make some header more consistent (e.g. examples vs example) and fix a couple minor things here and there. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-22Merge branch 'ma/parse-maybe-bool'Libravatar Junio C Hamano1-2/+2
Code clean-up. * ma/parse-maybe-bool: parse_decoration_style: drop unused argument `var` treewide: deprecate git_config_maybe_bool, use git_parse_maybe_bool config: make git_{config,parse}_maybe_bool equivalent config: introduce git_parse_maybe_bool_text t5334: document that git push --signed=1 does not work Doc/git-{push,send-pack}: correct --sign= to --signed=
2017-08-07Doc/git-{push,send-pack}: correct --sign= to --signed=Libravatar Martin Ågren1-2/+2
Since we're about to touch the behavior of --signed=, do this as a preparatory step. The documentation mentions --sign=, and it works. But that's just because it's an unambiguous abbreviation of --signed, which is how it is actually implemented. This was added in commit 30261094 ("push: support signing pushes iff the server supports it", 2015-08-19). Back when that series was developed [1] [2], there were suggestions about both --sign= and --signed=. The final implementation settled on --signed=, but some of the documentation and commit messages ended up using --sign=. The option is referred to as --signed= in Documentation/config.txt (under push.gpgSign). One could argue that we have promised --sign for two years now, so we should implement it as an alias for --signed. (Then we might also deprecate the latter, something which was considered already then.) That would be a slightly more intrusive change. This minor issue would only be a problem once we want to implement some other option --signfoo, but the earlier we do this step, the better. [1] v1-thread: https://public-inbox.org/git/1439492451-11233-1-git-send-email-dborowitz@google.com/T/#u [2] v2-thread: https://public-inbox.org/git/1439998007-28719-1-git-send-email-dborowitz@google.com/T/#m6533a6c4707a30b0d81e86169ff8559460cbf6eb Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-22remote-curl: allow push optionsLibravatar Brandon Williams1-0/+6
Teach remote-curl to understand push options and to be able to convey them across HTTP. Signed-off-by: Brandon Williams <bmwill@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset long command-line options as literalLibravatar Matthieu Moy1-5/+5
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>
2015-08-19push: support signing pushes iff the server supports itLibravatar Dave Borowitz1-6/+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-send-pack.txt: document --signedLibravatar Dave Borowitz1-1/+9
Signed-off-by: Dave Borowitz <dborowitz@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-19Documentation/git-send-pack.txt: wrap long synopsis lineLibravatar Dave Borowitz1-1/+3
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-1/+1
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-1/+1
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-01-07send-pack.c: add --atomic command line argumentLibravatar Ronnie Sahlberg1-1/+6
This adds support to send-pack to negotiate and use atomic pushes iff the server supports it. Atomic pushes are activated by a new command line flag --atomic. In order to do this we also need to change the semantics for send_pack() slightly. The existing send_pack() function actually doesn't send all the refs back to the server when multiple refs are involved, for example when using --all. Several of the failure modes for pushes can already be detected locally in the send_pack client based on the information from the initial server side list of all the refs as generated by receive-pack. Any such refs that we thus know would fail to push are thus pruned from the list of refs we send to the server to update. For atomic pushes, we have to deal thus with both failures that are detected locally as well as failures that are reported back from the server. In order to do so we treat all local failures as push failures too. We introduce a new status code REF_STATUS_ATOMIC_PUSH_FAILED so we can flag all refs that we would normally have tried to push to the server but we did not due to local failures. This is to improve the error message back to the end user to flag that "these refs failed to update since the atomic push operation failed." 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-08-26send-pack: take refspecs over stdinLibravatar Jeff King1-1/+12
Pushing a large number of refs works over most transports, because we implement send-pack as an internal function. However, it can sometimes fail when pushing over http, because we have to spawn "git send-pack --stateless-rpc" to do the heavy lifting, and we pass each refspec on the command line. This can cause us to overflow the OS limits on the size of the command line for a large push. We can solve this by giving send-pack a --stdin option and using it from remote-curl. We already dealt with this on the fetch-pack side in 078b895 (fetch-pack: new --stdin option to read refs from stdin, 2012-04-02). The stdin option (and in particular, its use of packet-lines for stateless-rpc input) is modeled after that solution. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-1/+1
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-06Revert "Merge branch 'cb/maint-quiet-push' into maint"Libravatar Junio C Hamano1-4/+1
This reverts commit ffa69e61d3c5730bd4b65a465efc130b0ef3c7df, reversing changes made to 4a13c4d14841343d7caad6ed41a152fee550261d. Adding a new command line option to receive-pack and feed it from send-pack is not an acceptable way to add features, as there is no guarantee that your updated send-pack will be talking to updated receive-pack. New features need to be added via the capability mechanism negotiated over the protocol. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-23Merge branch 'cb/maint-quiet-push' into maintLibravatar Junio C Hamano1-1/+4
* cb/maint-quiet-push: receive-pack: do not overstep command line argument array propagate --quiet to send-pack/receive-pack Conflicts: Documentation/git-receive-pack.txt Documentation/git-send-pack.txt
2011-07-31propagate --quiet to send-pack/receive-packLibravatar Clemens Buchacher1-1/+4
Currently, git push --quiet produces some non-error output, e.g.: $ git push --quiet Unpacking objects: 100% (3/3), done. Add the --quiet option to send-pack/receive-pack and pass it to unpack-objects in the receive-pack codepath and to receive-pack in the push codepath. This fixes a bug reported for the fedora git package: https://bugzilla.redhat.com/show_bug.cgi?id=725593 Reported-by: Jesse Keating <jkeating@redhat.com> Cc: Todd Zullinger <tmz@pobox.com> Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-06Documentation: use [verse] for SYNOPSIS sectionsLibravatar Martin von Zweigbergk1-0/+1
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-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-02-18Documentation: describe --thin more accuratelyLibravatar Stephen Boyd1-2/+2
The description for --thin was misleading and downright wrong. Correct it with some inspiration from the description of index-pack's --fix-thin and some background information from Nicolas Pitre <nico@fluxnic.net>. 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-10-24Use 'fast-forward' all over the placeLibravatar Felipe Contreras1-2/+2
It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-5/+5
The names of git commands are not meant to be entered at the commandline; they are just names. So we render them in italics, as is usual for command names in manpages. Using doit () { perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }' } for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \ merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt do doit <"$i" >"$i+" && mv "$i+" "$i" done git diff . Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation formatting and cleanupLibravatar Jonathan Nieder1-7/+7
Following what appears to be the predominant style, format names of commands and commandlines both as `teletype text`. While we're at it, add articles ("a" and "the") in some places, italicize the name of the command in the manual page synopsis line, and add a comma or two where it seems appropriate. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-1/+1
Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsLibravatar Stephan Beyer1-7/+7
The OPTIONS section of a documentation file contains a list of the options a git command accepts. Currently there are several variants to describe the case that different options (almost) do the same in the OPTIONS section. Some are: -f, --foo:: -f|--foo:: -f | --foo:: But AsciiDoc has the special form: -f:: --foo:: This patch applies this form to the documentation of the whole git suite, and removes useless em-dash prevention, so \--foo becomes --foo. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-06documentation: move git(7) to git(1)Libravatar Christian Couder1-1/+1
As the "git" man page describes the "git" command at the end-user level, it seems better to move it to man section 1. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-3/+3
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock Asciidoc configuration: @@ -149,7 +153,10 @@ # Inline macros. # Backslash prefix required for escape processing. # (?s) re flag for line spanning. -(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + +# Explicit so they can be nested. +(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + # Anchor: [[[id]]]. Bibliographic anchor. (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3 # Anchor: [[id,xreflabel]] This default regex now matches explicit values, and unfortunately in this case gitlink was being matched by just 'link', causing the wrong inline macro template to be applied. By renaming the macro, we can avoid being matched by the wrong regex. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-18push: use same rules as git-rev-parse to resolve refspecsLibravatar Steffen Prohaska1-1/+3
This commit changes the rules for resolving refspecs to match the rules for resolving refs in rev-parse. git-rev-parse uses clear rules to resolve a short ref to its full name, which are well documented. The rules for resolving refspecs documented in git-send-pack were less strict and harder to understand. This commit replaces them by the rules of git-rev-parse. The unified rules are easier to understand and better resolve ambiguous cases. You can now push from a repository containing several branches ending on the same short name. Note, this may break existing setups. For example, "master" will no longer resolve to "origin/master" even when there is no other "master" elsewhere. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-15Add a --dry-run option to git-send-pack.Libravatar Brian Ewins1-1/+4
Implement support for --dry-run, so that it can be used in calls from git-push. With this flag set, git-send-pack will not send any updates to the server. Signed-off-by: Brian Ewins <brian.ewins@gmail.com> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-18git-push: documentation and tests for pushing only branchesLibravatar Jeff King1-2/+2
Commit 098e711e caused git-push to match only branches when considering which refs to push. This patch updates the documentation accordingly and adds a test for this behavior. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-02-03Assorted typo fixesLibravatar Pavel Roskin1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19rename --exec to --receive-pack for push and send-packLibravatar Uwe Kleine-König1-2/+5
For now it's just to get a more descriptive name. Later we might update the push protocol to run more than one program on the other end. Moreover this matches better the corresponding config option remote.<name>. receivepack. --exec continues to work Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19Update documentation of fetch-pack, push and send-packLibravatar Uwe Kleine-König1-4/+11
add all supported options to Documentation/git-....txt and the usage strings. Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-18Documentation: sync git.txt command list and manual page titleLibravatar Junio C Hamano1-1/+1
Also reorders a handful entries to make each list sorted alphabetically. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation: suggest corresponding Porcelain-level in plumbing docs.Libravatar Junio C Hamano1-0/+3
Instead of keeping the confused end user reading low-level documentation, suggest the higher level commands that implement what the user may want to do using them upfront. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-12Documentation: add missing second colons and remove a typoLibravatar Rene Scharfe1-1/+1
It takes two colons to mark text as item label. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-03Documentation: Spelling fixesLibravatar Horst H. von Brand1-1/+1
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-09Remove trailing dot after short descriptionLibravatar Fredrik Kuivinen1-1/+1
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10Remove the version tags from the manpagesLibravatar Junio C Hamano1-1/+0
Signed-off-by: Christian Meder <chris@absolutegiganten.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03[PATCH] Random documentation fixesLibravatar Jonas Fonseca1-4/+4
The fixes focuses on improving the HTML output. Most noteworthy: - Fix the Makefile to also make various *.html files depend on included files. - Consistently use 'NOTE: ...' instead of '[ ... ]' for additional info. - Fix ending '::' for description lists in OPTION section etc. - Fix paragraphs in description lists ending up as preformated text. - Always use listingblocks (preformatted text wrapped in lines with -----) for examples that span empty lines, so they are put in only one HTML block. - Use '1.' instead of '(1)' for numbered lists. - Fix linking to other GIT docs. - git-rev-list.txt: put option descriptions in an OPTION section. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-20[PATCH] Documentation: Update all files to use the new gitlink: macroLibravatar Sergey Vlasov1-1/+1
The replacement was performed automatically by these commands: perl -pi -e 's/link:(git.+)\.html\[\1\]/gitlink:$1\[1\]/g' \ README Documentation/*.txt perl -pi -e 's/link:git\.html\[git\]/gitlink:git\[7\]/g' \ README Documentation/*.txt Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24Documentation: multi-head fetch.Libravatar Junio C Hamano1-9/+28
Add documentation related to multi-head work, including $GIT_DIR/remotes/ changes. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-03git-send-pack: documentationLibravatar Junio C Hamano1-1/+47
Describe the renaming push. The wording is horrible and I would appreciate a rewrite, but it is better than nothing ;-). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-14[PATCH] Documentation: send/receive.Libravatar Junio C Hamano1-0/+46
This adds documentation for 'smarter push' family of commands. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>