kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Martin Ågren	38cadf9e47	git-receive-pack.txt: wrap shell [script] listing in "----" The indented lines in the example shell script listing are indented differently by AsciiDoc and Asciidoctor. Fix this by marking the example shell script as a code listing by wrapping it in "----". Because this gives us some extra indentation, we can remove the one that we have been carrying explicitly. That is, drop the first tab of indentation on each line. For consistency, make the same change to the short example shell session further down. With AsciiDoc, this results in identical rendering before and after this commit. Asciidoctor now renders this the same as AsciiDoc does. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Nguyễn Thái Ngọc Duy	76a8788c14	doc: keep first level section header in upper case 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>	7 years ago
Jeff King	d8f4481c4f	refs: reject ref updates while GIT_QUARANTINE_PATH is set As documented in git-receive-pack(1), updating a ref from within the pre-receive hook is dangerous and can corrupt your repo. This patch forbids ref updates entirely during the hook to make it harder for adventurous hook writers to shoot themselves in the foot. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jeff King	eaeed077a6	receive-pack: document user-visible quarantine effects Commit `722ff7f87` (receive-pack: quarantine objects until pre-receive accepts, 2016-10-03) changed the underlying details of how we take in objects. This is mostly transparent to the user, but there are a few things they might notice. Let's document them. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jeff King	c08db5a2d0	receive-pack: allow a maximum input size to be specified Receive-pack feeds its input to either index-pack or unpack-objects, which will happily accept as many bytes as a sender is willing to provide. Let's allow an arbitrary cutoff point where we will stop writing bytes to disk. Cleaning up what has already been written to disk is a related problem that is not addressed by this patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Nguyễn Thái Ngọc Duy	da0005b885	*config.txt: stick to camelCase naming convention 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>	10 years ago
Junio C Hamano	5732373daa	signed push: allow stale nonce in stateless mode When operating with the stateless RPC mode, we will receive a nonce issued by another instance of us that advertised our capability and refs some time ago. Update the logic to check received nonce to detect this case, compute how much time has passed since the nonce was issued and report the status with a new environment variable GIT_PUSH_CERT_NONCE_SLOP to the hooks. GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The hooks are free to decide how large a slop it is willing to accept. Strictly speaking, the "nonce" is not really a "nonce" anymore in the stateless RPC mode, as it will happily take any "nonce" issued by it (which is protected by HMAC and its secret key) as long as it is fresh enough. The degree of this security degradation, relative to the native protocol, is about the same as the "we make sure that the 'git push' decided to update our refs with new objects based on the freshest observation of our refs by making sure the values they claim the original value of the refs they ask us to update exactly match the current state" security is loosened to accomodate the stateless RPC mode in the existing code without this series, so there is no need for those who are already using smart HTTP to push to their repositories to be alarmed any more than they already are. In addition, the server operator can set receive.certnonceslop configuration variable to specify how stale a nonce can be (in seconds). When this variable is set, and if the nonce received in the certificate that passes the HMAC check was less than that many seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS (instead of "SLOP") and the received nonce value is given in GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded hook to check if the certificate we received is recent enough. Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Junio C Hamano	b89363e4a5	signed push: fortify against replay attacks In order to prevent a valid push certificate for pushing into an repository from getting replayed in a different push operation, send a nonce string from the receive-pack process and have the signer include it in the push certificate. The receiving end uses an HMAC hash of the path to the repository it serves and the current time stamp, hashed with a secret seed (the secret seed does not have to be per-repository but can be defined in /etc/gitconfig) to generate the nonce, in order to ensure that a random third party cannot forge a nonce that looks like it originated from it. The original nonce is exported as GIT_PUSH_CERT_NONCE for the hooks to examine and match against the value on the "nonce" header in the certificate to notice a replay, but returned "nonce" header in the push certificate is examined by receive-pack and the result is exported as GIT_PUSH_CERT_NONCE_STATUS, whose value would be "OK" if the nonce recorded in the certificate matches what we expect, so that the hooks can more easily check. Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Junio C Hamano	d05b9618ce	receive-pack: GPG-validate push certificates Reusing the GPG signature check helpers we already have, verify the signature in receive-pack and give the results to the hooks via GIT_PUSH_CERT_{SIGNER,KEY,STATUS} environment variables. Policy decisions, such as accepting or rejecting a good signature by a key that is not fully trusted, is left to the hook and kept outside of the core. Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Junio C Hamano	a85b377d04	push: the beginning of "git push --signed" 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>	10 years ago
Junio C Hamano	5a277f3ff7	Revert "Merge branch 'cb/maint-quiet-push' into maint" This reverts commit `ffa69e61d3`, reversing changes made to `4a13c4d148`. 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>	14 years ago
Clemens Buchacher	90a6c7d443	propagate --quiet to send-pack/receive-pack 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>	14 years ago
Josh Triplett	d49483f0ca	ref namespaces: documentation Document the namespace mechanism in a new gitnamespaces(7) page. Reference it from receive-pack and upload-pack. Document the new --namespace option and GIT_NAMESPACE environment variable in git(1), and reference gitnamespaces(7). Add a sample Apache configuration to http-backend(1) to support namespaced repositories, and reference gitnamespaces(7). Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Jamey Sharp <jamey@minilop.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Martin von Zweigbergk	7791a1d9b9	Documentation: use [verse] for SYNOPSIS sections 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>	14 years ago
Jeff King	48bb914ed6	doc: drop author/documentation sections from most pages 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.	14 years ago
Thomas Rast	0b444cdb19	Documentation: spell 'git cmd' without dash throughout 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.	15 years ago
Felipe Contreras	a75d7b5409	Use 'fast-forward' all over the place It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Markus Heidelberg	04c8ce9c1c	Documentation: fix typos, grammar, asciidoc syntax Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Jonathan Nieder	ba020ef5eb	manpages: italicize git command names (which were in teletype font) 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>	17 years ago
Jonathan Nieder	483bc4f045	Documentation formatting and cleanup 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>	17 years ago
Jonathan Nieder	b1889c36d8	Documentation: be consistent about "git-" versus "git " 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>	17 years ago
Christian Couder	9e1f0a85c6	documentation: move git(7) to git(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>	17 years ago
Dan McGee	5162e69732	Documentation: rename gitlink macro to linkgit 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>	17 years ago
Brian Hetro	027830755d	Documentation: Correct various misspellings and typos. Fix minor typos throughout the documentation. Signed-off-by: Brian Hetro <whee@smaertness.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Jeff King	967506bbbd	Documentation: quote {non-attributes} for asciidoc Asciidoc treats {foo} as an attribute to be substituted; if 'foo' doesn't exist as an attribute, then the entire line gets dropped. When the literal {foo} is desired, \{foo} is required. The exceptions to this rule are: - inside literal blocks - if the 'foo' contains non-alphanumeric characters (e.g., {foo\|bar} is assumed not to be an attribute) Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Shawn O. Pearce	f43cd49fb8	Change {pre,post}-receive hooks to use stdin Sergey Vlasov, Andy Parkins and Alex Riesen all pointed out that it is possible for a single invocation of receive-pack to be given more refs than the OS might allow us to pass as command line parameters to a single hook invocation. We don't want to break these up into multiple invocations (like xargs might do) as that makes it impossible for the pre-receive hook to verify multiple related ref updates occur at the same time, and it makes it harder for post-receive to send out a single batch notification. Instead we pass the reference data on a pipe connected to the hook's stdin, supplying one ref per line to the hook. This way a single hook invocation can obtain an infinite amount of ref data, without bumping into any operating system limits. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Shawn O. Pearce	05ef58ec1f	Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	c3f0baacad	Documentation: sync git.txt command list and manual page title Also reorders a handful entries to make each list sorted alphabetically. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Johannes Schindelin	199a92186b	Document receive.denyNonFastforwards [jc: with a fix to config handling in t5400 test, which took annoyingly long to diagnose.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	efc7fa5355	Retire git-clone-pack The program is not used by git-clone since git-fetch-pack was extended to allow its caller do what git-clone-pack alone did, and git-clone was updated to use it. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	eb0362a467	Documentation: push/receive hook references. Mention documentation pages that talk about update and post-update hooks from git-push, because a frequently asked question is "I want X to happen when I push" and people would not know to look at git-receive-pack documentation until they understand that is what runs on the other end. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	98438bd0e8	Remove the version tags from the manpages Signed-off-by: Christian Meder <chris@absolutegiganten.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Sergey Vlasov	a7154e916c	[PATCH] Documentation: Update all files to use the new gitlink: macro 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>	20 years ago
Junio C Hamano	6d35cc7690	Document hooks. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	19614330dd	receive-pack hooks updates. The earlier one conflated update and post-update hooks for no good reason. Correct that ugly hack. Now post-update hooks will take the list of successfully updated refs. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Josef Weidendorfer	b1bf95bba2	[PATCH] Added hook in git-receive-pack Just before updating a ref, $GIT_DIR/hooks/update refname old-sha1 new-sha1 is called if executable. The hook can decline the ref to be updated by exiting with a non-zero status, or allow it to be updated by exiting with a zero status. The mechanism also allows e.g sending of a mail with pushed commits on the remote repository. Documentation update with an example hook is included. jc: The credits of the basic idea and initial implementation go to Josef, but I ended up rewriting major parts of his patch, so bugs are all mine. Also I changed the semantics for the hook from his original version (which were post-update hook) so that the hook can optionally decline to update the ref, and also can be used to implement the overall cleanups. The latter was primarily to implement a suggestion from Linus that calling update-server-info should be made optional. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	2a24501363	[PATCH] Documentation: send/receive. 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>	20 years ago

41 Commits (763b47bafab6f781dc52461985b3300d447d1332)