summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2009-11-04http-backend: Use http.getanyfile to disable dumb HTTP servingLibravatar Shawn O. Pearce1-0/+8
Some repository owners may wish to enable smart HTTP, but disallow dumb content serving. Disallowing dumb serving might be because the owners want to rely upon reachability to control which objects clients may access from the repository, or they just want to encourage clients to use the more bandwidth efficient transport. If http.getanyfile is set to false the backend CGI will return with '403 Forbidden' when an object file is accessed by a dumb client. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-04Smart push over HTTP: client sideLibravatar Shawn O. Pearce1-0/+8
The git-remote-curl backend detects if the remote server supports the git-receive-pack service, and if so, runs git-send-pack in a pipe to dump the command and pack data as a single POST request. The advertisements from the server that were obtained during the discovery are passed into git-send-pack before the POST request starts. This permits git-send-pack to operate largely unmodified. For smaller packs (those under 1 MiB) a HTTP/1.0 POST with a Content-Length is used, permitting interaction with any server. The 1 MiB limit is arbitrary, but is sufficent to fit most deltas created by human authors against text sources with the occasional small binary file (e.g. few KiB icon image). The configuration option http.postBuffer can be used to increase (or shink) this buffer if the default is not sufficient. For larger packs which cannot be spooled entirely into the helper's memory space (due to http.postBuffer being too small), the POST request requires HTTP/1.1 and sets "Transfer-Encoding: chunked". This permits the client to upload an unknown amount of data in one HTTP transaction without needing to pregenerate the entire pack file locally. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> CC: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-04http-backend: more explict LocationMatchLibravatar Mark Lodato1-1/+1
In the git-http-backend examples, only match git-receive-pack within /git/. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-04http-backend: add example for gitweb on same URLLibravatar Mark Lodato1-0/+33
In the git-http-backend documentation, add an example of how to set up gitweb and git-http-backend on the same URL by using a series of mod_alias commands. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-04http-backend: use mod_alias instead of mod_rewriteLibravatar Mark Lodato1-7/+3
In the git-http-backend documentation, use mod_alias exlusively, instead of using a combination of mod_alias and mod_rewrite. This makes the example slightly shorted and a bit more clear. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-04http-backend: reword some documentationLibravatar Mark Lodato1-4/+8
Clarify some of the git-http-backend documentation, particularly: * In the Description, state that smart/dumb HTTP fetch and smart HTTP push are supported, state that authenticated clients allow push, and remove the note that this is only suited for read-only updates. * At the start of Examples, state explicitly what URL is mapping to what location on disk. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-04http-backend: add GIT_PROJECT_ROOT environment varLibravatar Mark Lodato1-22/+17
Add a new environment variable, GIT_PROJECT_ROOT, to override the method of using PATH_TRANSLATED to find the git repository on disk. This makes it much easier to configure the web server, especially when the web server's DocumentRoot does not contain the git repositories, which is the usual case. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-04Smart fetch and push over HTTP: server sideLibravatar Shawn O. Pearce1-1/+38
Requests for $GIT_URL/git-receive-pack and $GIT_URL/git-upload-pack are forwarded to the corresponding backend process by directly executing it and leaving stdin and stdout connected to the invoking web server. Prior to starting the backend process the HTTP response headers are sent, thereby freeing the backend from needing to know about the HTTP protocol. Requests that are encoded with Content-Encoding: gzip are automatically inflated before being streamed into the backend. This is primarily useful for the git-upload-pack backend, which receives highly repetitive text data from clients that easily compresses to 50% of its original size. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-04Git-aware CGI to provide dumb HTTP transportLibravatar Shawn O. Pearce1-0/+105
The git-http-backend CGI can be configured into any Apache server using ScriptAlias, such as with the following configuration: LoadModule cgi_module /usr/libexec/apache2/mod_cgi.so LoadModule alias_module /usr/libexec/apache2/mod_alias.so ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ Repositories are accessed via the translated PATH_INFO. The CGI is backwards compatible with the dumb client, allowing all older HTTP clients to continue to download repositories which are managed by the CGI. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-30Move WebDAV HTTP push under remote-curlLibravatar Shawn O. Pearce1-1/+32
The remote helper interface now supports the push capability, which can be used to ask the implementation to push one or more specs to the remote repository. For remote-curl we implement this by calling the existing WebDAV based git-http-push executable. Internally the helper interface uses the push_refs transport hook so that the complexity of the refspec parsing and matching can be reused between remote implementations. When possible however the helper protocol uses source ref name rather than the source SHA-1, thereby allowing the helper to access this name if it is useful. >From Clemens Buchacher <drizzd@aon.at>: update http tests according to remote-curl capabilities o Pushing packed refs is now fixed. o The transport helper fails if refs are already up-to-date. Add a test for that. o The transport helper will notice if refs are already up-to-date. We therefore need to update server info in the unpacked-refs test. o The transport helper will purge deleted branches automatically. o Use a variable ($ORIG_HEAD) instead of full SHA-1 name. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> CC: Daniel Barkalow <barkalow@iabervon.org> CC: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-30remote-helpers: Support custom transport optionsLibravatar Shawn O. Pearce1-0/+38
Some transports, like the native pack transport implemented by fetch-pack, support useful features like depth or include tags. These should be exposed if the underlying helper knows how to use them. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> CC: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-30remote-helpers: Fetch more than one ref in a batchLibravatar Shawn O. Pearce1-4/+10
Some network protocols (e.g. native git://) are able to fetch more than one ref at a time and reduce the overall transfer cost by combining the requests into a single exchange. Instead of feeding each fetch request one at a time to the helper, feed all of them at once so the helper can decide whether or not it should batch them. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> CC: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-13Merge branch 'maint-1.6.4' into maintLibravatar Junio C Hamano1-1/+2
* maint-1.6.4: git-stash documentation: mention default options for 'list'
2009-10-12git-stash documentation: mention default options for 'list'Libravatar Miklos Vajna1-1/+2
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-10GIT 1.6.5Libravatar Junio C Hamano2-6/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-09Documentation: clone: clarify discussion of initial branchLibravatar Jonathan Nieder1-2/+3
When saying the initial branch is equal to the currently active remote branch, it is probably intended that the branch heads point to the same commit. Maybe it would be more useful to a new user to emphasize that the tree contents and history are the same. More important, probably, is that this new branch is set up so that "git pull" merges changes from the corresponding remote branch. The next paragraph addresses that directly. What the reader needs to know to begin with is that (1) the initial branch is your own; if you do not pull, it won't get updated, and that (2) the initial branch starts out at the same commit as the upstream. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-09racy-git.txt: explain nsec problem in more detailLibravatar Jonathan Nieder1-4/+6
Idealists may want USE_NSEC to be the default on Linux some day. Point to a patch to better explain the requirements on filesystem code for that to happen. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-09Documentation: clarify "working tree" definitionLibravatar Jonathan Nieder1-3/+3
It is not necessarily obvious to a git novice what it means for a filesystem tree to be equal to the HEAD. Spell it out. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-09Documentation: clarify branch creationLibravatar Jonathan Nieder1-8/+8
The documentation seems to assume that the starting point for a new branch is the tip of an existing (ordinary) branch, but that is not the most common case. More often, "git branch" is used to begin a branch from a remote-tracking branch, a tag, or an interesting commit (e.g. origin/pu^2). Clarify the language so it can apply to these cases. Thanks to Sean Estabrooks for the wording. Also add a pointer to the user's manual for the bewildered. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-09Documentation: branch: update --merged descriptionLibravatar Jonathan Nieder1-4/+6
Update the documentation for --merged and --no-merged to explain the meaning of the optional parameter introduced in commit 049716b (branch --merged/--no-merged: allow specifying arbitrary commit, 2008-07-08). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-09Documentation: clarify mergeoptions descriptionLibravatar Jonathan Nieder2-3/+3
Sounds better this way, at least to my ears. ("The syntax and supported options of git merge" is a plural noun. "the same" instead of "equal" sounds less technical and seems to convey the meaning better here.) Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-09Documentation: git fmt-merge-msg does not have to be a scriptLibravatar Jonathan Nieder2-5/+6
The fmt-merge-message builtin can be invoked as "git fmt-merge-msg" rather than through the hard link in GIT_EXEC_PATH. Although this is unlikely to confuse most script writers, it should not hurt to make the documentation a little clearer anyway. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-08Update draft release notes to 1.6.5Libravatar Junio C Hamano1-6/+10
2009-10-02filter-branch: add --prune-empty to option summaryLibravatar Adam Brewster1-0/+1
Signed-off-by: Adam Brewster <adambrewster@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2009-09-29Documentation/git-gc.txt: default --aggressive window is 250, not 10Libravatar Brandon Casey1-1/+1
The default --aggressive window has been 250 since 1c192f34 "gc --aggressive: make it really aggressive", released in git v1.6.3. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-09-22Update "describe" documentation to match realityLibravatar Thiago Farina1-1/+1
A sample "git describe -h" did not match what the program actually says. Signed-off-by: Thiago Farina <tfransosi@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-21Update Release Notes to 1.6.5Libravatar Junio C Hamano1-4/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-16Merge 1.6.4.4 inLibravatar Junio C Hamano2-1/+28
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-16GIT 1.6.4.4Libravatar Junio C Hamano2-1/+28
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-14remove logical typo in documentation of sample update hookLibravatar Heiko Voigt1-1/+1
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13git-archive: infer output format from filename when unspecifiedLibravatar Dmitry Potapov1-2/+11
A command line $ git archive -o my-v2.0.zip v2.0 almost certainly wants the output in zip format, even though it does not specify any --format option. When --format is not given, but output filename is, try to infer what format is requested from the filename extension. Currently this code only knows about '.zip'. When the format is unspecified and the filename does not tell us, the output will be in 'tar' format as before. Of course, an explicit --format will not trigger this guesswork. Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13git-archive: add '-o' as a alias for '--output'Libravatar Dmitry Potapov1-1/+2
The '-o' option is commonly used in many tools to specify the output file. Typing '--output' every time is a bit too long to be a practical alternative to redirecting output. But specifying the output name has the advantage of making possible to guess the desired output format by filename extension. Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13git-clone doc: typofixLibravatar Johannes Gilger1-1/+1
Signed-off-by: Johannes Gilger <heipei@hackvalue.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13git-push: Accept -n as a synonym for --dry-run.Libravatar Nelson Elhage1-1/+2
git-push is not currently using -n for anything else, and it seems unlikely we will want to use it to mean anything else in the future, so add it as an alias for convenience. Signed-off-by: Nelson Elhage <nelhage@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13git-commit doc: remove duplicated --dry-run descriptionLibravatar Junio C Hamano1-7/+1
60c2993 (Documentation/git-commit.txt: describe --dry-run, 2009-08-15) wanted to update the documentation to say that "git status" is not the same as "git commit --dry-run" anymore, but it screwed up and also added the description of --dry-run that was already present. Noticed by Johannes Gilger. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13GIT 1.6.5-rc1Libravatar Junio C Hamano1-0/+31
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13Improve --patch option documentation in git-addLibravatar Jari Aalto1-3/+8
Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13Merge branch 'jt/pushinsteadof'Libravatar Junio C Hamano2-0/+31
* jt/pushinsteadof: Add url.<base>.pushInsteadOf: URL rewriting for push only Wrap rewrite globals in a struct in preparation for adding another set
2009-09-13Merge branch 'jk/unwanted-advices'Libravatar Junio C Hamano1-0/+15
* jk/unwanted-advices: status: make "how to stage" messages optional push: make non-fast-forward help message configurable
2009-09-13quiltimport documentation: --dry-run and -n are synonymsLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13Merge branch 'db/vcs-helper'Libravatar Junio C Hamano1-0/+71
* db/vcs-helper: Makefile: remove remnant of separate http/https/ftp helpers Use a clearer style to issue commands to remote helpers Make the "traditionally-supported" URLs a special case Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible Makefile: do not link three copies of git-remote-* programs Makefile: git-http-fetch does not need expat http-fetch: Fix Makefile dependancies Add transport native helper executables to .gitignore git-http-fetch: not a builtin Use an external program to implement fetching with curl Add support for external programs for handling native fetches
2009-09-13Merge branch 'maint'Libravatar Junio C Hamano2-1/+31
* maint: GIT 1.6.4.3 svn: properly escape arguments for authors-prog http.c: remove verification of remote packs grep: accept relative paths outside current working directory grep: fix exit status if external_grep() punts Conflicts: GIT-VERSION-GEN RelNotes
2009-09-13GIT 1.6.4.3Libravatar Junio C Hamano2-1/+31
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-11status: make "how to stage" messages optionalLibravatar Jeff King1-0/+4
These messages are nice for new users, but experienced git users know how to manipulate the index, and these messages waste a lot of screen real estate. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-11push: make non-fast-forward help message configurableLibravatar Jeff King1-0/+11
This message is designed to help new users understand what has happened when refs fail to push. However, it does not help experienced users at all, and significantly clutters the output, frequently dwarfing the regular status table and making it harder to see. This patch introduces a general configuration mechanism for optional messages, with this push message as the first example. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-11add documentation for mailinfo.scissors and '--no-scissors'Libravatar Nicolas Sebrecht2-1/+9
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-08Add url.<base>.pushInsteadOf: URL rewriting for push onlyLibravatar Josh Triplett2-0/+31
This configuration option allows systematically rewriting fetch-only URLs to push-capable URLs when used with push. For instance: [url "ssh://example.org/"] pushInsteadOf = "git://example.org/" This will allow clones of "git://example.org/path/to/repo" to subsequently push to "ssh://example.org/path/to/repo", without manually configuring pushurl for that remote. Includes documentation for the new option, bash completion updates, and test cases (both that pushInsteadOf applies to push, that it does not apply to fetch, and that it is ignored when pushURL is already defined). Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-07GIT 1.6.5-rc0Libravatar Junio C Hamano1-6/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-07Merge branch 'maint'Libravatar Junio C Hamano2-15/+20
* maint: git-pull: do not mention --quiet and --verbose twice githooks.txt: put hooks into subsections
2009-09-07git-pull: do not mention --quiet and --verbose twiceLibravatar Emmanuel Trillaud1-0/+2
git-pull.txt includes fetch-options.txt and merge-options.txt, both of which document the --quiet and --verbose. Supress the ones from fetch-options.txt. Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>