summaryrefslogtreecommitdiff
path: root/Documentation/git-shell.txt
AgeCommit message (Collapse)AuthorFilesLines
2018-05-02doc: keep first level section header in upper caseLibravatar Nguyễn Thái Ngọc Duy1-2/+2
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-09-12shell: drop git-cvsserver support by defaultLibravatar Jeff King1-0/+16
The git-cvsserver script is old and largely unmaintained these days. But git-shell allows untrusted users to run it out of the box, significantly increasing its attack surface. Let's drop it from git-shell's list of internal handlers so that it cannot be run by default. This is not backwards compatible. But given the age and development activity on CVS-related parts of Git, this is likely to impact very few users, while helping many more (i.e., anybody who runs git-shell and had no intention of supporting CVS). There's no configuration mechanism in git-shell for us to add a boolean and flip it to "off". But there is a mechanism for adding custom commands, and adding CVS support here is fairly trivial. Let's document it to give guidance to anybody who really is still running cvsserver. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset short command-line options as literalLibravatar Matthieu Moy1-2/+2
It was common in our documentation to surround short option names with forward quotes, which renders as italic in HTML. Instead, use backquotes which renders as monospace. This is one more step toward conformance to Documentation/CodingGuidelines. This was obtained with: perl -pi -e "s/'(-[a-z])'/\`\$1\`/g" *.txt Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-08shell doc: remove stray "+" in exampleLibravatar Jonathan Nieder1-1/+1
The git-shell(1) manpage says EXAMPLE To disable interactive logins, displaying a greeting instead: + $ chsh -s /usr/bin/git-shell $ mkdir $HOME/git-shell-commands [...] The stray "+" has been there ever since the example was added in v1.8.3-rc0~210^2 (shell: new no-interactive-login command to print a custom message, 2013-03-09). The "+" sign between paragraphs is needed in asciidoc to attach extra paragraphs to a list item but here it is not needed and ends up rendered as a literal "+". Remove it. A quick search with "grep -e '<p>+' /usr/share/doc/git/html/*.html" doesn't find any other instances of this problem. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-09shell: new no-interactive-login command to print a custom messageLibravatar Jonathan Nieder1-0/+20
If I disable git-shell's interactive mode by removing the ~/git-shell-commands directory, attempts to ssh in to the service produce a message intended for the administrator: $ ssh git@myserver fatal: Interactive git shell is not enabled. hint: ~/git-shell-commands should exist and have read and execute access. $ That is helpful for the new admin who is wondering "What? Why isn't the git-shell I just set up working?", but once the site setup is complete, it would be better to give the user a friendly hint that she is on the right track, like GitHub does. Hi <username>! You've successfully authenticated, but GitHub does not provide shell access. An appropriate greeting might even include more complex dynamic information, like gitolite's list of repositories the user has access to. Add support for a ~/git-shell-commands/no-interactive-login command that generates an arbitrary greeting. When the user tries to log in: * If the file ~/git-shell-commands/no-interactive-login exists, run no-interactive-login to let the server say what it likes, then hang up. * Otherwise, if ~/git-shell-commands/ is present, start an interactive read-eval-print loop. * Otherwise, print the usual configuration hint and hang up. Reported-by: Ethan Reesor <firelizzard@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Improved-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-09shell doc: emphasize purpose and security modelLibravatar Jonathan Nieder1-13/+49
The original git-shell(1) manpage emphasized that the shell supports only git transport commands. As the shell gained features, that emphasis and focus in the manual has been lost. Bring it back by splitting the manpage into a few short sections and fleshing out each: - SYNOPSIS, describing how the shell gets used in practice - DESCRIPTION, which gives an overview of the purpose and guarantees provided by this restricted shell - COMMANDS, listing supported commands and restrictions on the arguments they accept - INTERACTIVE USE, describing the interactive mode Also add a "see also" section with related reading. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 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-8/+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-08-24shell: Rewrite documentation and improve error messageLibravatar Ramkumar Ramachandra1-11/+17
Update the documentation of 'git shell' to mention the interactive mode and COMMAND_DIR. Also provide a hint when interactive mode is not available in the shell. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Greg Brockman <gdb@MIT.EDU> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11git-shell: Add 'git-upload-archive' to allowed commands.Libravatar Erik Broes1-3/+3
This allows for example gitosis to allow use of 'git archive --remote' in a controlled environment. Signed-off-by: Erik Broes <erikbroes@ripe.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-19shell: Document that 'cvs server' is a valid commandLibravatar Lars Noschinski1-2/+3
git-shell's man page explicitly lists all allowed commands, but 'cvs server' was missing. Add it. Signed-off-by: Lars Noschinski <lars@public.noschinski.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-1/+1
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-1/+1
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-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-1/+1
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-06-07War on whitespaceLibravatar Junio C Hamano1-1/+0
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
2006-03-05git/Documentation: fix SYNOPSIS style bugsLibravatar Dmitry V. Levin1-1/+1
This trivial patch fixes SYNOPSIS style bugs. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-25Documentation for git-shellLibravatar Petr Baudis1-0/+35
Signed-off-by: Junio C Hamano <junkio@cox.net>