Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Autogenerated HTML docs for v1.9-rc1

  • Loading branch information...
commit c5bd79e0cb5f924e05e9e6cdb64a4be2ade572e1 1 parent fd98be8
Junio C Hamano authored
46 RelNotes/1.9.txt
View
@@ -87,6 +87,8 @@ Foreign interfaces, subsystems and ports.
* The build procedure is aware of MirBSD now.
+ * Various "git p4", "git svn" and "gitk" updates.
+
UI, Workflows & Features
@@ -215,6 +217,50 @@ Unless otherwise noted, all the fixes since v1.8.5 in the maintenance
track are contained in this release (see the maintenance releases' notes
for details).
+ * The pathspec matching code, while comparing two trees (e.g. "git
+ diff A B -- path1 path2") was too agrresive and failed to match
+ some paths when multiple pathspecs were involved.
+ (merge e4ddb05 as/tree-walk-fix-aggressive-short-cut later to maint).
+
+ * "git repack --max-pack-size=8g" stopped being parsed correctly when
+ the command was reimplemented in C.
+ (merge b861e23 sb/repack-in-c later to maint).
+
+ * An earlier update in v1.8.4.x to "git rev-list --objects" with
+ negative ref had performance regression.
+ (merge 200abe7 jk/mark-edges-uninteresting later to maint).
+
+ * A recent update to "git send-email" broke platforms where
+ /etc/ssl/certs/ directory exists, but it cannot used as SSL_ca_path
+ (e.g. Fedora rawhide).
+ (merge 01645b7 rk/send-email-ssl-cert later to maint).
+
+ * A handful of bugs around interpreting $branch@{upstream} notation
+ and its lookalike, when $branch part has interesting characters,
+ e.g. "@", and ":", have been fixed.
+ (merge 9892d5d jk/interpret-branch-name-fix later to maint).
+
+ * "git clone" would fail to clone from a repository that has a ref
+ directly under "refs/", e.g. "refs/stash", because different
+ validation paths do different things on such a refname. Loosen the
+ client side's validation to allow such a ref.
+ (merge 4c22408 jk/allow-fetch-onelevel-refname later to maint).
+
+ * "git log --left-right A...B" lost the "leftness" of commits
+ reachable from A when A is a tag as a side effect of a recent
+ bugfix. This is a regression in 1.8.4.x series.
+ (merge a743528 jc/revision-range-unpeel later to maint).
+
+ * documentations to "git pull" hinted there is an "-m" option because
+ it incorrectly shared the documentation with "git merge".
+ (merge 08f19cf jc/maint-pull-docfix later to maint).
+
+ * "git diff A B submod" and "git diff A B submod/" ought to have done
+ the same for a submodule "submod", but didn't.
+
+ * "git clone $origin foo\bar\baz" on Windows failed to create the
+ leading directories (i.e. a moral-equivalent of "mkdir -p").
+
* "submodule.*.update=checkout", when propagated from .gitmodules to
.git/config, turned into a "submodule.*.update=none", which did not
make much sense.
6 git-checkout.html
View
@@ -1073,8 +1073,8 @@ <h2 id="_options">OPTIONS</h2>
commit, your HEAD becomes "detached" and you are no longer on
any branch (see below for details).
</p>
-<div class="paragraph"><p>As a special case, the <tt>"@{-N}"</tt> syntax for the N-th last branch
-checks out the branch (instead of detaching). You may also specify
+<div class="paragraph"><p>As a special case, the <tt>"@{-N}"</tt> syntax for the N-th last branch/commit
+checks out branches (instead of detaching). You may also specify
<tt>-</tt> which is synonymous with <tt>"@{-1}"</tt>.</p></div>
<div class="paragraph"><p>As a further special case, you may use <tt>"A...B"</tt> as a shortcut for the
merge base of <tt>A</tt> and <tt>B</tt> if there is exactly one merge base. You can
@@ -1365,7 +1365,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-10-17 21:34:27 PDT
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
4 git-checkout.txt
View
@@ -232,8 +232,8 @@ section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
commit, your HEAD becomes "detached" and you are no longer on
any branch (see below for details).
+
-As a special case, the `"@{-N}"` syntax for the N-th last branch
-checks out the branch (instead of detaching). You may also specify
+As a special case, the `"@{-N}"` syntax for the N-th last branch/commit
+checks out branches (instead of detaching). You may also specify
`-` which is synonymous with `"@{-1}"`.
+
As a further special case, you may use `"A...B"` as a shortcut for the
8 git-column.html
View
@@ -831,12 +831,6 @@ <h2 id="_options">OPTIONS</h2>
</div>
</div>
<div class="sect1">
-<h2 id="_author">Author</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Written by Nguyen Thai Ngoc Duy &lt;<a href="mailto:pclouds@gmail.com">pclouds@gmail.com</a>&gt;</p></div>
-</div>
-</div>
-<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@@ -846,7 +840,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
5 git-column.txt
View
@@ -43,11 +43,6 @@ OPTIONS
--padding=<N>::
The number of spaces between columns. One space by default.
-
-Author
-------
-Written by Nguyen Thai Ngoc Duy <pclouds@gmail.com>
-
GIT
---
Part of the linkgit:git[1] suite
14 git-for-each-ref.html
View
@@ -1030,18 +1030,6 @@ <h2 id="_examples">EXAMPLES</h2>
</div>
</div>
<div class="sect1">
-<h2 id="_author">Author</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Written by Junio C Hamano &lt;<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>&gt;.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_documentation">Documentation</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Documentation by Junio C Hamano and the git-list &lt;<a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a>&gt;.</p></div>
-</div>
-</div>
-<div class="sect1">
<h2 id="_see_also">SEE ALSO</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="git-show-ref.html">git-show-ref(1)</a></p></div>
@@ -1057,7 +1045,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2014-01-22 14:45:04 PST
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
8 git-for-each-ref.txt
View
@@ -219,14 +219,6 @@ eval=`git for-each-ref --shell --format="$fmt" \
eval "$eval"
------------
-Author
-------
-Written by Junio C Hamano <gitster@pobox.com>.
-
-Documentation
--------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
SEE ALSO
--------
linkgit:git-show-ref[1]
14 git-http-backend.html
View
@@ -1062,18 +1062,6 @@ <h2 id="_environment">ENVIRONMENT</h2>
</div>
</div>
<div class="sect1">
-<h2 id="_author">Author</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Written by Shawn O. Pearce &lt;<a href="mailto:spearce@spearce.org">spearce@spearce.org</a>&gt;.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_documentation">Documentation</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Documentation by Shawn O. Pearce &lt;<a href="mailto:spearce@spearce.org">spearce@spearce.org</a>&gt;.</p></div>
-</div>
-</div>
-<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@@ -1083,7 +1071,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
8 git-http-backend.txt
View
@@ -263,14 +263,6 @@ identifying information of the remote user who performed the push.
All CGI environment variables are available to each of the hooks
invoked by the 'git-receive-pack'.
-Author
-------
-Written by Shawn O. Pearce <spearce@spearce.org>.
-
-Documentation
---------------
-Documentation by Shawn O. Pearce <spearce@spearce.org>.
-
GIT
---
Part of the linkgit:git[1] suite
7 git-merge.html
View
@@ -835,9 +835,10 @@ <h2 id="_options">OPTIONS</h2>
further edit the auto-generated merge message, so that the user
can explain and justify the merge. The <tt>--no-edit</tt> option can be
used to accept the auto-generated message (this is generally
- discouraged). The <tt>--edit</tt> (or <tt>-e</tt>) option is still useful if you are
- giving a draft message with the <tt>-m</tt> option from the command line
- and want to edit it in the editor.
+ discouraged).
+The <tt>--edit</tt> (or <tt>-e</tt>) option is still useful if you are
+giving a draft message with the <tt>-m</tt> option from the command line
+and want to edit it in the editor.
</p>
<div class="paragraph"><p>Older scripts may depend on the historical behaviour of not allowing the
user to edit the merge log message. They will see an editor opened when
15 git-notes.html
View
@@ -1297,19 +1297,6 @@ <h2 id="_environment">ENVIRONMENT</h2>
</div>
</div>
<div class="sect1">
-<h2 id="_author">Author</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Written by Johannes Schindelin &lt;<a href="mailto:johannes.schindelin@gmx.de">johannes.schindelin@gmx.de</a>&gt; and
-Johan Herland &lt;<a href="mailto:johan@herland.net">johan@herland.net</a>&gt;</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_documentation">Documentation</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Documentation by Johannes Schindelin and Johan Herland</p></div>
-</div>
-</div>
-<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(7)</a> suite</p></div>
@@ -1319,7 +1306,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
10 git-notes.txt
View
@@ -375,16 +375,6 @@ does not match any refs is silently ignored.
If not set in the environment, the list of notes to copy depends
on the `notes.rewrite.<command>` and `notes.rewriteRef` settings.
-
-Author
-------
-Written by Johannes Schindelin <johannes.schindelin@gmx.de> and
-Johan Herland <johan@herland.net>
-
-Documentation
--------------
-Documentation by Johannes Schindelin and Johan Herland
-
GIT
---
Part of the linkgit:git[7] suite
12 git-p4.html
View
@@ -941,7 +941,10 @@ <h3 id="_general_options">General options</h3>
</p>
</dd>
<dt class="hdlist1">
---verbose, -v
+-v
+</dt>
+<dt class="hdlist1">
+--verbose
</dt>
<dd>
<p>
@@ -1145,7 +1148,10 @@ <h3 id="_submit_options">Submit options</h3>
</p>
</dd>
<dt class="hdlist1">
---dry-run, -n
+-n
+</dt>
+<dt class="hdlist1">
+--dry-run
</dt>
<dd>
<p>
@@ -1648,7 +1654,7 @@ <h2 id="_implementation_details">IMPLEMENTATION DETAILS</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
6 git-p4.txt
View
@@ -168,7 +168,8 @@ All commands except clone accept these options.
--git-dir <dir>::
Set the 'GIT_DIR' environment variable. See linkgit:git[1].
---verbose, -v::
+-v::
+--verbose::
Provide more progress information.
Sync options
@@ -279,7 +280,8 @@ These options can be used to modify 'git p4 submit' behavior.
Export tags from Git as p4 labels. Tags found in Git are applied
to the perforce working directory.
---dry-run, -n::
+-n::
+--dry-run::
Show just what commits would be submitted to p4; do not change
state in Git or p4.
44 git-pull.html
View
@@ -885,9 +885,7 @@ <h3 id="_options_related_to_merging">Options related to merging</h3>
further edit the auto-generated merge message, so that the user
can explain and justify the merge. The <tt>--no-edit</tt> option can be
used to accept the auto-generated message (this is generally
- discouraged). The <tt>--edit</tt> (or <tt>-e</tt>) option is still useful if you are
- giving a draft message with the <tt>-m</tt> option from the command line
- and want to edit it in the editor.
+ discouraged).
</p>
<div class="paragraph"><p>Older scripts may depend on the historical behaviour of not allowing the
user to edit the merge log message. They will see an editor opened when
@@ -1029,44 +1027,6 @@ <h3 id="_options_related_to_merging">Options related to merging</h3>
</p>
</dd>
<dt class="hdlist1">
--q
-</dt>
-<dt class="hdlist1">
---quiet
-</dt>
-<dd>
-<p>
- Operate quietly. Implies --no-progress.
-</p>
-</dd>
-<dt class="hdlist1">
--v
-</dt>
-<dt class="hdlist1">
---verbose
-</dt>
-<dd>
-<p>
- Be verbose.
-</p>
-</dd>
-<dt class="hdlist1">
---progress
-</dt>
-<dt class="hdlist1">
---no-progress
-</dt>
-<dd>
-<p>
- Turn progress on/off explicitly. If neither is specified,
- progress is shown if standard error is connected to a terminal.
- Note that not all merge strategies may support progress
- reporting.
-</p>
-</dd>
-</dl></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-r
</dt>
<dt class="hdlist1">
@@ -1915,7 +1875,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-11-06 15:55:05 PST
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
4 git-pull.txt
View
@@ -99,10 +99,10 @@ must be given before the options meant for 'git fetch'.
Options related to merging
~~~~~~~~~~~~~~~~~~~~~~~~~~
-include::merge-options.txt[]
-
:git-pull: 1
+include::merge-options.txt[]
+
-r::
--rebase[=false|true|preserve]::
When true, rebase the current branch on top of the upstream
9 git-remote-ext.html
View
@@ -948,13 +948,6 @@ <h2 id="_examples">EXAMPLES:</h2>
</div>
</div>
<div class="sect1">
-<h2 id="_documentation">Documentation</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Documentation by Ilari Liusvaara, Jonathan Nieder and the Git list
-&lt;<a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a>&gt;</p></div>
-</div>
-</div>
-<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@@ -964,7 +957,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
5 git-remote-ext.txt
View
@@ -116,11 +116,6 @@ begins with `ext::`. Examples:
determined by the helper using environment variables (see
above).
-Documentation
---------------
-Documentation by Ilari Liusvaara, Jonathan Nieder and the Git list
-<git@vger.kernel.org>
-
GIT
---
Part of the linkgit:git[1] suite
8 git-remote-fd.html
View
@@ -828,12 +828,6 @@ <h2 id="_examples">EXAMPLES</h2>
</div>
</div>
<div class="sect1">
-<h2 id="_documentation">Documentation</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Documentation by Ilari Liusvaara and the Git list &lt;<a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a>&gt;</p></div>
-</div>
-</div>
-<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@@ -843,7 +837,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
4 git-remote-fd.txt
View
@@ -50,10 +50,6 @@ EXAMPLES
`git push fd::7,8/bar master`::
Same as above.
-Documentation
---------------
-Documentation by Ilari Liusvaara and the Git list <git@vger.kernel.org>
-
GIT
---
Part of the linkgit:git[1] suite
2  git-rev-parse.html
View
@@ -1353,7 +1353,7 @@ <h2 id="_specifying_revisions">SPECIFYING REVISIONS</h2>
</dt>
<dd>
<p>
- The construct <em>@{-&lt;n&gt;}</em> means the &lt;n&gt;th branch checked out
+ The construct <em>@{-&lt;n&gt;}</em> means the &lt;n&gt;th branch/commit checked out
before the current one.
</p>
</dd>
11 gitattributes.html
View
@@ -1771,9 +1771,12 @@ <h2 id="_using_macro_attributes">USING MACRO ATTRIBUTES</h2>
<div class="sect1">
<h2 id="_defining_macro_attributes">DEFINING MACRO ATTRIBUTES</h2>
<div class="sectionbody">
-<div class="paragraph"><p>Custom macro attributes can be defined only in the <tt>.gitattributes</tt>
-file at the toplevel (i.e. not in any subdirectory). The built-in
-macro attribute "binary" is equivalent to:</p></div>
+<div class="paragraph"><p>Custom macro attributes can be defined only in top-level gitattributes
+files (<tt>$GIT_DIR/info/attributes</tt>, the <tt>.gitattributes</tt> file at the
+top level of the working tree, or the global or system-wide
+gitattributes files), not in <tt>.gitattributes</tt> files in working tree
+subdirectories. The built-in macro attribute "binary" is equivalent
+to:</p></div>
<div class="listingblock">
<div class="content">
<pre><tt>[attr]binary -diff -merge -text</tt></pre>
@@ -1854,7 +1857,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
9 gitattributes.txt
View
@@ -930,9 +930,12 @@ state.
DEFINING MACRO ATTRIBUTES
-------------------------
-Custom macro attributes can be defined only in the `.gitattributes`
-file at the toplevel (i.e. not in any subdirectory). The built-in
-macro attribute "binary" is equivalent to:
+Custom macro attributes can be defined only in top-level gitattributes
+files (`$GIT_DIR/info/attributes`, the `.gitattributes` file at the
+top level of the working tree, or the global or system-wide
+gitattributes files), not in `.gitattributes` files in working tree
+subdirectories. The built-in macro attribute "binary" is equivalent
+to:
------------
[attr]binary -diff -merge -text
4 gitignore.html
View
@@ -749,7 +749,7 @@
<div class="sect1">
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
-<div class="paragraph"><p>$GIT_DIR/info/exclude, .gitignore</p></div>
+<div class="paragraph"><p>$HOME/.config/git/ignore, $GIT_DIR/info/exclude, .gitignore</p></div>
</div>
</div>
<div class="sect1">
@@ -1018,7 +1018,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-12-17 15:53:46 PST
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
2  gitignore.txt
View
@@ -7,7 +7,7 @@ gitignore - Specifies intentionally untracked files to ignore
SYNOPSIS
--------
-$GIT_DIR/info/exclude, .gitignore
+$HOME/.config/git/ignore, $GIT_DIR/info/exclude, .gitignore
DESCRIPTION
-----------
54 gitk.html
View
@@ -887,6 +887,58 @@ <h3 id="_rev_list_options_and_arguments">rev-list options and arguments</h3>
</p>
</dd>
<dt class="hdlist1">
+-L&lt;start&gt;,&lt;end&gt;:&lt;file&gt;
+</dt>
+<dt class="hdlist1">
+-L:&lt;regex&gt;:&lt;file&gt;
+</dt>
+<dd>
+<p>
+ Trace the evolution of the line range given by "&lt;start&gt;,&lt;end&gt;"
+ (or the funcname regex &lt;regex&gt;) within the &lt;file&gt;. You may
+ not give any pathspec limiters. This is currently limited to
+ a walk starting from a single revision, i.e., you may only
+ give zero or one positive revision arguments.
+ You can specify this option more than once.
+</p>
+<div class="paragraph"><p><strong>Note:</strong> gitk (unlike <a href="git-log.html">git-log(1)</a>) currently only understands
+this option if you specify it "glued together" with its argument. Do
+<strong>not</strong> put a space after <tt>-L</tt>.</p></div>
+<div class="paragraph"><p>&lt;start&gt; and &lt;end&gt; can take one of these forms:</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+number
+</p>
+<div class="paragraph"><p>If &lt;start&gt; or &lt;end&gt; is a number, it specifies an
+absolute line number (lines count from 1).</p></div>
+</li>
+<li>
+<p>
+/regex/
+</p>
+<div class="paragraph"><p>This form will use the first line matching the given
+POSIX regex. If &lt;start&gt; is a regex, it will search from the end of
+the previous <tt>-L</tt> range, if any, otherwise from the start of file.
+If &lt;start&gt; is &#8220;^/regex/&#8221;, it will search from the start of file.
+If &lt;end&gt; is a regex, it will search
+starting at the line given by &lt;start&gt;.</p></div>
+</li>
+<li>
+<p>
++offset or -offset
+</p>
+<div class="paragraph"><p>This is only valid for &lt;end&gt; and will specify a number
+of lines before or after the line given by &lt;start&gt;.</p></div>
+</li>
+</ul></div>
+<div class="paragraph"><p>If &#8220;:&lt;regex&gt;&#8221; is given in place of &lt;start&gt; and &lt;end&gt;, it denotes the range
+from the first funcname line that matches &lt;regex&gt;, up to the next
+funcname line. &#8220;:&lt;regex&gt;&#8221; searches from the end of the previous <tt>-L</tt> range,
+if any, otherwise from the start of file.
+&#8220;^:&lt;regex&gt;&#8221; searches from the start of file.</p></div>
+</dd>
+<dt class="hdlist1">
&lt;revision range&gt;
</dt>
<dd>
@@ -1033,7 +1085,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-10-30 14:54:47 PDT
+Last updated 2014-01-27 13:30:07 PST
</div>
</div>
</body>
16 gitk.txt
View
@@ -98,6 +98,22 @@ linkgit:git-rev-list[1] for a complete list.
(See "History simplification" in linkgit:git-log[1] for a more
detailed explanation.)
+-L<start>,<end>:<file>::
+-L:<regex>:<file>::
+
+ Trace the evolution of the line range given by "<start>,<end>"
+ (or the funcname regex <regex>) within the <file>. You may
+ not give any pathspec limiters. This is currently limited to
+ a walk starting from a single revision, i.e., you may only
+ give zero or one positive revision arguments.
+ You can specify this option more than once.
++
+*Note:* gitk (unlike linkgit:git-log[1]) currently only understands
+this option if you specify it "glued together" with its argument. Do
+*not* put a space after `-L`.
++
+include::line-range-format.txt[]
+
<revision range>::
Limit the revisions to show. This can be either a single revision
2  gitrevisions.html
View
@@ -912,7 +912,7 @@ <h2 id="_specifying_revisions">SPECIFYING REVISIONS</h2>
</dt>
<dd>
<p>
- The construct <em>@{-&lt;n&gt;}</em> means the &lt;n&gt;th branch checked out
+ The construct <em>@{-&lt;n&gt;}</em> means the &lt;n&gt;th branch/commit checked out
before the current one.
</p>
</dd>
9 merge-options.txt
View
@@ -14,9 +14,12 @@ inspect and further tweak the merge result before committing.
further edit the auto-generated merge message, so that the user
can explain and justify the merge. The `--no-edit` option can be
used to accept the auto-generated message (this is generally
- discouraged). The `--edit` (or `-e`) option is still useful if you are
- giving a draft message with the `-m` option from the command line
- and want to edit it in the editor.
+ discouraged).
+ifndef::git-pull[]
+The `--edit` (or `-e`) option is still useful if you are
+giving a draft message with the `-m` option from the command line
+and want to edit it in the editor.
+endif::git-pull[]
+
Older scripts may depend on the historical behaviour of not allowing the
user to edit the merge log message. They will see an editor opened when
2  revisions.txt
View
@@ -88,7 +88,7 @@ some output processing may assume ref names in UTF-8.
branch 'blabla' then '@\{1\}' means the same as 'blabla@\{1\}'.
'@\{-<n>\}', e.g. '@\{-1\}'::
- The construct '@\{-<n>\}' means the <n>th branch checked out
+ The construct '@\{-<n>\}' means the <n>th branch/commit checked out
before the current one.
'<branchname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
1,244 technical/http-protocol.html
View
@@ -0,0 +1,1244 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
+ "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
+<meta name="generator" content="AsciiDoc 8.6.6" />
+<title>HTTP transfer protocols</title>
+<style type="text/css">
+/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
+
+/* Default font. */
+body {
+ font-family: Georgia,serif;
+}
+
+/* Title font. */
+h1, h2, h3, h4, h5, h6,
+div.title, caption.title,
+thead, p.table.header,
+#toctitle,
+#author, #revnumber, #revdate, #revremark,
+#footer {
+ font-family: Arial,Helvetica,sans-serif;
+}
+
+body {
+ margin: 1em 5% 1em 5%;
+}
+
+a {
+ color: blue;
+ text-decoration: underline;
+}
+a:visited {
+ color: fuchsia;
+}
+
+em {
+ font-style: italic;
+ color: navy;
+}
+
+strong {
+ font-weight: bold;
+ color: #083194;
+}
+
+h1, h2, h3, h4, h5, h6 {
+ color: #527bbd;
+ margin-top: 1.2em;
+ margin-bottom: 0.5em;
+ line-height: 1.3;
+}
+
+h1, h2, h3 {
+ border-bottom: 2px solid silver;
+}
+h2 {
+ padding-top: 0.5em;
+}
+h3 {
+ float: left;
+}
+h3 + * {
+ clear: left;
+}
+h5 {
+ font-size: 1.0em;
+}
+
+div.sectionbody {
+ margin-left: 0;
+}
+
+hr {
+ border: 1px solid silver;
+}
+
+p {
+ margin-top: 0.5em;
+ margin-bottom: 0.5em;
+}
+
+ul, ol, li > p {
+ margin-top: 0;
+}
+ul > li { color: #aaa; }
+ul > li > * { color: black; }
+
+pre {
+ padding: 0;
+ margin: 0;
+}
+
+#author {
+ color: #527bbd;
+ font-weight: bold;
+ font-size: 1.1em;
+}
+#email {
+}
+#revnumber, #revdate, #revremark {
+}
+
+#footer {
+ font-size: small;
+ border-top: 2px solid silver;
+ padding-top: 0.5em;
+ margin-top: 4.0em;
+}
+#footer-text {
+ float: left;
+ padding-bottom: 0.5em;
+}
+#footer-badges {
+ float: right;
+ padding-bottom: 0.5em;
+}
+
+#preamble {
+ margin-top: 1.5em;
+ margin-bottom: 1.5em;
+}
+div.imageblock, div.exampleblock, div.verseblock,
+div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
+div.admonitionblock {
+ margin-top: 1.0em;
+ margin-bottom: 1.5em;
+}
+div.admonitionblock {
+ margin-top: 2.0em;
+ margin-bottom: 2.0em;
+ margin-right: 10%;
+ color: #606060;
+}
+
+div.content { /* Block element content. */
+ padding: 0;
+}
+
+/* Block element titles. */
+div.title, caption.title {
+ color: #527bbd;
+ font-weight: bold;
+ text-align: left;
+ margin-top: 1.0em;
+ margin-bottom: 0.5em;
+}
+div.title + * {
+ margin-top: 0;
+}
+
+td div.title:first-child {
+ margin-top: 0.0em;
+}
+div.content div.title:first-child {
+ margin-top: 0.0em;
+}
+div.content + div.title {
+ margin-top: 0.0em;
+}
+
+div.sidebarblock > div.content {
+ background: #ffffee;
+ border: 1px solid #dddddd;
+ border-left: 4px solid #f0f0f0;
+ padding: 0.5em;
+}
+
+div.listingblock > div.content {
+ border: 1px solid #dddddd;
+ border-left: 5px solid #f0f0f0;
+ background: #f8f8f8;
+ padding: 0.5em;
+}
+
+div.quoteblock, div.verseblock {
+ padding-left: 1.0em;
+ margin-left: 1.0em;
+ margin-right: 10%;
+ border-left: 5px solid #f0f0f0;
+ color: #888;
+}
+
+div.quoteblock > div.attribution {
+ padding-top: 0.5em;
+ text-align: right;
+}
+
+div.verseblock > pre.content {
+ font-family: inherit;
+ font-size: inherit;
+}
+div.verseblock > div.attribution {
+ padding-top: 0.75em;
+ text-align: left;
+}
+/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
+div.verseblock + div.attribution {
+ text-align: left;
+}
+
+div.admonitionblock .icon {
+ vertical-align: top;
+ font-size: 1.1em;
+ font-weight: bold;
+ text-decoration: underline;
+ color: #527bbd;
+ padding-right: 0.5em;
+}
+div.admonitionblock td.content {
+ padding-left: 0.5em;
+ border-left: 3px solid #dddddd;
+}
+
+div.exampleblock > div.content {
+ border-left: 3px solid #dddddd;
+ padding-left: 0.5em;
+}
+
+div.imageblock div.content { padding-left: 0; }
+span.image img { border-style: none; }
+a.image:visited { color: white; }
+
+dl {
+ margin-top: 0.8em;
+ margin-bottom: 0.8em;
+}
+dt {
+ margin-top: 0.5em;
+ margin-bottom: 0;
+ font-style: normal;
+ color: navy;
+}
+dd > *:first-child {
+ margin-top: 0.1em;
+}
+
+ul, ol {
+ list-style-position: outside;
+}
+ol.arabic {
+ list-style-type: decimal;
+}
+ol.loweralpha {
+ list-style-type: lower-alpha;
+}
+ol.upperalpha {
+ list-style-type: upper-alpha;
+}
+ol.lowerroman {
+ list-style-type: lower-roman;
+}
+ol.upperroman {
+ list-style-type: upper-roman;
+}
+
+div.compact ul, div.compact ol,
+div.compact p, div.compact p,
+div.compact div, div.compact div {
+ margin-top: 0.1em;
+ margin-bottom: 0.1em;
+}
+
+tfoot {
+ font-weight: bold;
+}
+td > div.verse {
+ white-space: pre;
+}
+
+div.hdlist {
+ margin-top: 0.8em;
+ margin-bottom: 0.8em;
+}
+div.hdlist tr {
+ padding-bottom: 15px;
+}
+dt.hdlist1.strong, td.hdlist1.strong {
+ font-weight: bold;
+}
+td.hdlist1 {
+ vertical-align: top;
+ font-style: normal;
+ padding-right: 0.8em;
+ color: navy;
+}
+td.hdlist2 {
+ vertical-align: top;
+}
+div.hdlist.compact tr {
+ margin: 0;
+ padding-bottom: 0;
+}
+
+.comment {
+ background: yellow;
+}
+
+.footnote, .footnoteref {
+ font-size: 0.8em;
+}
+
+span.footnote, span.footnoteref {
+ vertical-align: super;
+}
+
+#footnotes {
+ margin: 20px 0 20px 0;
+ padding: 7px 0 0 0;
+}
+
+#footnotes div.footnote {
+ margin: 0 0 5px 0;
+}
+
+#footnotes hr {
+ border: none;
+ border-top: 1px solid silver;
+ height: 1px;
+ text-align: left;
+ margin-left: 0;
+ width: 20%;
+ min-width: 100px;
+}
+
+div.colist td {
+ padding-right: 0.5em;
+ padding-bottom: 0.3em;
+ vertical-align: top;
+}
+div.colist td img {
+ margin-top: 0.3em;
+}
+
+@media print {
+ #footer-badges { display: none; }
+}
+
+#toc {
+ margin-bottom: 2.5em;
+}
+
+#toctitle {
+ color: #527bbd;
+ font-size: 1.1em;
+ font-weight: bold;
+ margin-top: 1.0em;
+ margin-bottom: 0.1em;
+}
+
+div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
+ margin-top: 0;
+ margin-bottom: 0;
+}
+div.toclevel2 {
+ margin-left: 2em;
+ font-size: 0.9em;
+}
+div.toclevel3 {
+ margin-left: 4em;
+ font-size: 0.9em;
+}
+div.toclevel4 {
+ margin-left: 6em;
+ font-size: 0.9em;
+}
+
+span.aqua { color: aqua; }
+span.black { color: black; }
+span.blue { color: blue; }
+span.fuchsia { color: fuchsia; }
+span.gray { color: gray; }
+span.green { color: green; }
+span.lime { color: lime; }
+span.maroon { color: maroon; }
+span.navy { color: navy; }
+span.olive { color: olive; }
+span.purple { color: purple; }
+span.red { color: red; }
+span.silver { color: silver; }
+span.teal { color: teal; }
+span.white { color: white; }
+span.yellow { color: yellow; }
+
+span.aqua-background { background: aqua; }
+span.black-background { background: black; }
+span.blue-background { background: blue; }
+span.fuchsia-background { background: fuchsia; }
+span.gray-background { background: gray; }
+span.green-background { background: green; }
+span.lime-background { background: lime; }
+span.maroon-background { background: maroon; }
+span.navy-background { background: navy; }
+span.olive-background { background: olive; }
+span.purple-background { background: purple; }
+span.red-background { background: red; }
+span.silver-background { background: silver; }
+span.teal-background { background: teal; }
+span.white-background { background: white; }
+span.yellow-background { background: yellow; }
+
+span.big { font-size: 2em; }
+span.small { font-size: 0.6em; }
+
+span.underline { text-decoration: underline; }
+span.overline { text-decoration: overline; }
+span.line-through { text-decoration: line-through; }
+
+
+/*
+ * xhtml11 specific
+ *
+ * */
+
+tt {
+ font-family: monospace;
+ font-size: inherit;
+ color: navy;
+}
+
+div.tableblock {
+ margin-top: 1.0em;
+ margin-bottom: 1.5em;
+}
+div.tableblock > table {
+ border: 3px solid #527bbd;
+}
+thead, p.table.header {
+ font-weight: bold;
+ color: #527bbd;
+}
+p.table {
+ margin-top: 0;
+}
+/* Because the table frame attribute is overriden by CSS in most browsers. */
+div.tableblock > table[frame="void"] {
+ border-style: none;
+}
+div.tableblock > table[frame="hsides"] {
+ border-left-style: none;
+ border-right-style: none;
+}
+div.tableblock > table[frame="vsides"] {
+ border-top-style: none;
+ border-bottom-style: none;
+}
+
+
+/*
+ * html5 specific
+ *
+ * */
+
+.monospaced {
+ font-family: monospace;
+ font-size: inherit;
+ color: navy;
+}
+
+table.tableblock {
+ margin-top: 1.0em;
+ margin-bottom: 1.5em;
+}
+thead, p.tableblock.header {
+ font-weight: bold;
+ color: #527bbd;
+}
+p.tableblock {
+ margin-top: 0;
+}
+table.tableblock {
+ border-width: 3px;
+ border-spacing: 0px;
+ border-style: solid;
+ border-color: #527bbd;
+ border-collapse: collapse;
+}
+th.tableblock, td.tableblock {
+ border-width: 1px;
+ padding: 4px;
+ border-style: solid;
+ border-color: #527bbd;
+}
+
+table.tableblock.frame-topbot {
+ border-left-style: hidden;
+ border-right-style: hidden;
+}
+table.tableblock.frame-sides {
+ border-top-style: hidden;
+ border-bottom-style: hidden;
+}
+table.tableblock.frame-none {
+ border-style: hidden;
+}
+
+th.tableblock.halign-left, td.tableblock.halign-left {
+ text-align: left;
+}
+th.tableblock.halign-center, td.tableblock.halign-center {
+ text-align: center;
+}
+th.tableblock.halign-right, td.tableblock.halign-right {
+ text-align: right;
+}
+
+th.tableblock.valign-top, td.tableblock.valign-top {
+ vertical-align: top;
+}
+th.tableblock.valign-middle, td.tableblock.valign-middle {
+ vertical-align: middle;
+}
+th.tableblock.valign-bottom, td.tableblock.valign-bottom {
+ vertical-align: bottom;
+}
+
+
+/*
+ * manpage specific
+ *
+ * */
+
+body.manpage h1 {
+ padding-top: 0.5em;
+ padding-bottom: 0.5em;
+ border-top: 2px solid silver;
+ border-bottom: 2px solid silver;
+}
+body.manpage h2 {
+ border-style: none;
+}
+body.manpage div.sectionbody {
+ margin-left: 3em;
+}
+
+@media print {
+ body.manpage div#toc { display: none; }
+}
+</style>
+<script type="text/javascript">
+/*<![CDATA[*/
+var asciidoc = { // Namespace.
+
+/////////////////////////////////////////////////////////////////////
+// Table Of Contents generator
+/////////////////////////////////////////////////////////////////////
+
+/* Author: Mihai Bazon, September 2002
+ * http://students.infoiasi.ro/~mishoo
+ *
+ * Table Of Content generator
+ * Version: 0.4
+ *
+ * Feel free to use this script under the terms of the GNU General Public
+ * License, as long as you do not remove or alter this notice.
+ */
+
+ /* modified by Troy D. Hanson, September 2006. License: GPL */
+ /* modified by Stuart Rackham, 2006, 2009. License: GPL */
+
+// toclevels = 1..4.
+toc: function (toclevels) {
+
+ function getText(el) {
+ var text = "";
+ for (var i = el.firstChild; i != null; i = i.nextSibling) {
+ if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
+ text += i.data;
+ else if (i.firstChild != null)
+ text += getText(i);
+ }
+ return text;
+ }
+
+ function TocEntry(el, text, toclevel) {
+ this.element = el;
+ this.text = text;
+ this.toclevel = toclevel;
+ }
+
+ function tocEntries(el, toclevels) {
+ var result = new Array;
+ var re = new RegExp('[hH]([2-'+(toclevels+1)+'])');
+ // Function that scans the DOM tree for header elements (the DOM2
+ // nodeIterator API would be a better technique but not supported by all
+ // browsers).
+ var iterate = function (el) {
+ for (var i = el.firstChild; i != null; i = i.nextSibling) {
+ if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
+ var mo = re.exec(i.tagName);
+ if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
+ result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
+ }
+ iterate(i);
+ }
+ }
+ }
+ iterate(el);
+ return result;
+ }
+
+ var toc = document.getElementById("toc");
+ if (!toc) {
+ return;
+ }
+
+ // Delete existing TOC entries in case we're reloading the TOC.
+ var tocEntriesToRemove = [];
+ var i;
+ for (i = 0; i < toc.childNodes.length; i++) {
+ var entry = toc.childNodes[i];
+ if (entry.nodeName == 'div'
+ && entry.getAttribute("class")
+ && entry.getAttribute("class").match(/^toclevel/))
+ tocEntriesToRemove.push(entry);
+ }
+ for (i = 0; i < tocEntriesToRemove.length; i++) {
+ toc.removeChild(tocEntriesToRemove[i]);
+ }
+
+ // Rebuild TOC entries.
+ var entries = tocEntries(document.getElementById("content"), toclevels);
+ for (var i = 0; i < entries.length; ++i) {
+ var entry = entries[i];
+ if (entry.element.id == "")
+ entry.element.id = "_toc_" + i;
+ var a = document.createElement("a");
+ a.href = "#" + entry.element.id;
+ a.appendChild(document.createTextNode(entry.text));
+ var div = document.createElement("div");
+ div.appendChild(a);
+ div.className = "toclevel" + entry.toclevel;
+ toc.appendChild(div);
+ }
+ if (entries.length == 0)
+ toc.parentNode.removeChild(toc);
+},
+
+
+/////////////////////////////////////////////////////////////////////
+// Footnotes generator
+/////////////////////////////////////////////////////////////////////
+
+/* Based on footnote generation code from:
+ * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
+ */
+
+footnotes: function () {
+ // Delete existing footnote entries in case we're reloading the footnodes.
+ var i;
+ var noteholder = document.getElementById("footnotes");
+ if (!noteholder) {
+ return;
+ }
+ var entriesToRemove = [];
+ for (i = 0; i < noteholder.childNodes.length; i++) {
+ var entry = noteholder.childNodes[i];
+ if (entry.nodeName == 'div' && entry.getAttribute("class") == "footnote")
+ entriesToRemove.push(entry);
+ }
+ for (i = 0; i < entriesToRemove.length; i++) {
+ noteholder.removeChild(entriesToRemove[i]);
+ }
+
+ // Rebuild footnote entries.
+ var cont = document.getElementById("content");
+ var spans = cont.getElementsByTagName("span");
+ var refs = {};
+ var n = 0;
+ for (i=0; i<spans.length; i++) {
+ if (spans[i].className == "footnote") {
+ n++;
+ var note = spans[i].getAttribute("data-note");
+ if (!note) {
+ // Use [\s\S] in place of . so multi-line matches work.
+ // Because JavaScript has no s (dotall) regex flag.
+ note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
+ spans[i].innerHTML =
+ "[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
+ "' title='View footnote' class='footnote'>" + n + "</a>]";
+ spans[i].setAttribute("data-note", note);
+ }
+ noteholder.innerHTML +=
+ "<div class='footnote' id='_footnote_" + n + "'>" +
+ "<a href='#_footnoteref_" + n + "' title='Return to text'>" +
+ n + "</a>. " + note + "</div>";
+ var id =spans[i].getAttribute("id");
+ if (id != null) refs["#"+id] = n;
+ }
+ }
+ if (n == 0)
+ noteholder.parentNode.removeChild(noteholder);
+ else {
+ // Process footnoterefs.
+ for (i=0; i<spans.length; i++) {
+ if (spans[i].className == "footnoteref") {
+ var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
+ href = href.match(/#.*/)[0]; // Because IE return full URL.
+ n = refs[href];
+ spans[i].innerHTML =
+ "[<a href='#_footnote_" + n +
+ "' title='View footnote' class='footnote'>" + n + "</a>]";
+ }
+ }
+ }
+},
+
+install: function(toclevels) {
+ var timerId;
+
+ function reinstall() {
+ asciidoc.footnotes();
+ if (toclevels) {
+ asciidoc.toc(toclevels);
+ }
+ }
+
+ function reinstallAndRemoveTimer() {
+ clearInterval(timerId);
+ reinstall();
+ }
+
+ timerId = setInterval(reinstall, 500);
+ if (document.addEventListener)
+ document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
+ else
+ window.onload = reinstallAndRemoveTimer;
+}
+
+}
+asciidoc.install();
+/*]]>*/
+</script>
+</head>
+<body class="article">
+<div id="header">
+<h1>HTTP transfer protocols</h1>
+</div>
+<div id="content">
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph"><p>Git supports two HTTP based transfer protocols. A "dumb" protocol
+which requires only a standard HTTP server on the server end of the
+connection, and a "smart" protocol which requires a Git aware CGI
+(or server module). This document describes both protocols.</p></div>
+<div class="paragraph"><p>As a design feature smart clients can automatically upgrade "dumb"
+protocol URLs to smart URLs. This permits all users to have the
+same published URL, and the peers automatically select the most
+efficient transport available to them.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_url_format">URL Format</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>URLs for Git repositories accessed by HTTP use the standard HTTP
+URL syntax documented by RFC 1738, so they are of the form:</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>http://&lt;host&gt;:&lt;port&gt;/&lt;path&gt;?&lt;searchpart&gt;</tt></pre>
+</div></div>
+<div class="paragraph"><p>Within this documentation the placeholder <tt>$GIT_URL</tt> will stand for
+the http:// repository URL entered by the end-user.</p></div>
+<div class="paragraph"><p>Servers SHOULD handle all requests to locations matching <tt>$GIT_URL</tt>, as
+both the "smart" and "dumb" HTTP protocols used by Git operate
+by appending additional path components onto the end of the user
+supplied <tt>$GIT_URL</tt> string.</p></div>
+<div class="paragraph"><p>An example of a dumb client requesting for a loose object:</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>$GIT_URL: http://example.com:8080/git/repo.git
+URL request: http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355</tt></pre>
+</div></div>
+<div class="paragraph"><p>An example of a smart request to a catch-all gateway:</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>$GIT_URL: http://example.com/daemon.cgi?svc=git&amp;q=
+URL request: http://example.com/daemon.cgi?svc=git&amp;q=/info/refs&amp;service=git-receive-pack</tt></pre>
+</div></div>
+<div class="paragraph"><p>An example of a request to a submodule:</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>$GIT_URL: http://example.com/git/repo.git/path/submodule.git
+URL request: http://example.com/git/repo.git/path/submodule.git/info/refs</tt></pre>
+</div></div>
+<div class="paragraph"><p>Clients MUST strip a trailing <tt>/</tt>, if present, from the user supplied
+<tt>$GIT_URL</tt> string to prevent empty path tokens (<tt>//</tt>) from appearing
+in any URL sent to a server. Compatible clients MUST expand
+<tt>$GIT_URL/info/refs</tt> as <tt>foo/info/refs</tt> and not <tt>foo//info/refs</tt>.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_authentication">Authentication</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>Standard HTTP authentication is used if authentication is required
+to access a repository, and MAY be configured and enforced by the
+HTTP server software.</p></div>
+<div class="paragraph"><p>Because Git repositories are accessed by standard path components
+server administrators MAY use directory based permissions within
+their HTTP server to control repository access.</p></div>
+<div class="paragraph"><p>Clients SHOULD support Basic authentication as described by RFC 2616.
+Servers SHOULD support Basic authentication by relying upon the
+HTTP server placed in front of the Git server software.</p></div>
+<div class="paragraph"><p>Servers SHOULD NOT require HTTP cookies for the purposes of
+authentication or access control.</p></div>
+<div class="paragraph"><p>Clients and servers MAY support other common forms of HTTP based
+authentication, such as Digest authentication.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_ssl">SSL</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>Clients and servers SHOULD support SSL, particularly to protect
+passwords when relying on Basic HTTP authentication.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_session_state">Session State</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>The Git over HTTP protocol (much like HTTP itself) is stateless
+from the perspective of the HTTP server side. All state MUST be
+retained and managed by the client process. This permits simple
+round-robin load-balancing on the server side, without needing to
+worry about state management.</p></div>
+<div class="paragraph"><p>Clients MUST NOT require state management on the server side in
+order to function correctly.</p></div>
+<div class="paragraph"><p>Servers MUST NOT require HTTP cookies in order to function correctly.
+Clients MAY store and forward HTTP cookies during request processing
+as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore any
+cookies sent by a client.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_general_request_processing">General Request Processing</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>Except where noted, all standard HTTP behavior SHOULD be assumed
+by both client and server. This includes (but is not necessarily
+limited to):</p></div>
+<div class="paragraph"><p>If there is no repository at <tt>$GIT_URL</tt>, or the resource pointed to by a
+location matching <tt>$GIT_URL</tt> does not exist, the server MUST NOT respond
+with <tt>200 OK</tt> response. A server SHOULD respond with
+<tt>404 Not Found</tt>, <tt>410 Gone</tt>, or any other suitable HTTP status code
+which does not imply the resource exists as requested.</p></div>
+<div class="paragraph"><p>If there is a repository at <tt>$GIT_URL</tt>, but access is not currently
+permitted, the server MUST respond with the <tt>403 Forbidden</tt> HTTP
+status code.</p></div>
+<div class="paragraph"><p>Servers SHOULD support both HTTP 1.0 and HTTP 1.1.
+Servers SHOULD support chunked encoding for both request and response
+bodies.</p></div>
+<div class="paragraph"><p>Clients SHOULD support both HTTP 1.0 and HTTP 1.1.
+Clients SHOULD support chunked encoding for both request and response
+bodies.</p></div>
+<div class="paragraph"><p>Servers MAY return ETag and/or Last-Modified headers.</p></div>
+<div class="paragraph"><p>Clients MAY revalidate cached entities by including If-Modified-Since
+and/or If-None-Match request headers.</p></div>
+<div class="paragraph"><p>Servers MAY return <tt>304 Not Modified</tt> if the relevant headers appear
+in the request and the entity has not changed. Clients MUST treat
+<tt>304 Not Modified</tt> identical to <tt>200 OK</tt> by reusing the cached entity.</p></div>
+<div class="paragraph"><p>Clients MAY reuse a cached entity without revalidation if the
+Cache-Control and/or Expires header permits caching. Clients and
+servers MUST follow RFC 2616 for cache controls.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_discovering_references">Discovering References</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>All HTTP clients MUST begin either a fetch or a push exchange by
+discovering the references available on the remote repository.</p></div>
+<div class="sect2">
+<h3 id="_dumb_clients">Dumb Clients</h3>
+<div class="paragraph"><p>HTTP clients that only support the "dumb" protocol MUST discover
+references by making a request for the special info/refs file of
+the repository.</p></div>
+<div class="paragraph"><p>Dumb HTTP clients MUST make a <tt>GET</tt> request to <tt>$GIT_URL/info/refs</tt>,
+without any search/query parameters.</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>C: GET $GIT_URL/info/refs HTTP/1.0</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>S: 200 OK
+S:
+S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
+S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
+S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
+S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}</tt></pre>
+</div></div>
+<div class="paragraph"><p>The Content-Type of the returned info/refs entity SHOULD be
+<tt>text/plain; charset=utf-8</tt>, but MAY be any content type.
+Clients MUST NOT attempt to validate the returned Content-Type.
+Dumb servers MUST NOT return a return type starting with
+<tt>application/x-git-</tt>.</p></div>
+<div class="paragraph"><p>Cache-Control headers MAY be returned to disable caching of the
+returned entity.</p></div>
+<div class="paragraph"><p>When examining the response clients SHOULD only examine the HTTP
+status code. Valid responses are <tt>200 OK</tt>, or <tt>304 Not Modified</tt>.</p></div>
+<div class="paragraph"><p>The returned content is a UNIX formatted text file describing
+each ref and its known value. The file SHOULD be sorted by name
+according to the C locale ordering. The file SHOULD NOT include
+the default ref named <tt>HEAD</tt>.</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>info_refs = *( ref_record )
+ref_record = any_ref / peeled_ref</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>any_ref = obj-id HTAB refname LF
+peeled_ref = obj-id HTAB refname LF
+ obj-id HTAB refname "^{}" LF</tt></pre>
+</div></div>
+</div>
+<div class="sect2">
+<h3 id="_smart_clients">Smart Clients</h3>
+<div class="paragraph"><p>HTTP clients that support the "smart" protocol (or both the
+"smart" and "dumb" protocols) MUST discover references by making
+a parameterized request for the info/refs file of the repository.</p></div>
+<div class="paragraph"><p>The request MUST contain exactly one query parameter,
+<tt>service=$servicename</tt>, where <tt>$servicename</tt> MUST be the service
+name the client wishes to contact to complete the operation.
+The request MUST NOT contain additional query parameters.</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0</tt></pre>
+</div></div>
+<div class="paragraph"><p>dumb server reply:</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>S: 200 OK
+S:
+S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
+S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
+S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
+S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}</tt></pre>
+</div></div>
+<div class="paragraph"><p>smart server reply:</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>S: 200 OK
+S: Content-Type: application/x-git-upload-pack-advertisement
+S: Cache-Control: no-cache
+S:
+S: 001e# service=git-upload-pack\n
+S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0multi_ack\n
+S: 0042d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n
+S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n
+S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n</tt></pre>
+</div></div>
+<div class="sect3">
+<h4 id="_dumb_server_response">Dumb Server Response</h4>
+<div class="paragraph"><p>Dumb servers MUST respond with the dumb server reply format.</p></div>
+<div class="paragraph"><p>See the prior section under dumb clients for a more detailed
+description of the dumb server response.</p></div>
+</div>
+<div class="sect3">
+<h4 id="_smart_server_response">Smart Server Response</h4>
+<div class="paragraph"><p>If the server does not recognize the requested service name, or the
+requested service name has been disabled by the server administrator,
+the server MUST respond with the <tt>403 Forbidden</tt> HTTP status code.</p></div>
+<div class="paragraph"><p>Otherwise, smart servers MUST respond with the smart server reply
+format for the requested service name.</p></div>
+<div class="paragraph"><p>Cache-Control headers SHOULD be used to disable caching of the
+returned entity.</p></div>
+<div class="paragraph"><p>The Content-Type MUST be <tt>application/x-$servicename-advertisement</tt>.
+Clients SHOULD fall back to the dumb protocol if another content
+type is returned. When falling back to the dumb protocol clients
+SHOULD NOT make an additional request to <tt>$GIT_URL/info/refs</tt>, but
+instead SHOULD use the response already in hand. Clients MUST NOT
+continue if they do not support the dumb protocol.</p></div>
+<div class="paragraph"><p>Clients MUST validate the status code is either <tt>200 OK</tt> or
+<tt>304 Not Modified</tt>.</p></div>
+<div class="paragraph"><p>Clients MUST validate the first five bytes of the response entity
+matches the regex <tt>^[0-9a-f]{4}#</tt>. If this test fails, clients
+MUST NOT continue.</p></div>
+<div class="paragraph"><p>Clients MUST parse the entire response as a sequence of pkt-line
+records.</p></div>
+<div class="paragraph"><p>Clients MUST verify the first pkt-line is <tt># service=$servicename</tt>.
+Servers MUST set $servicename to be the request parameter value.
+Servers SHOULD include an LF at the end of this line.
+Clients MUST ignore an LF at the end of the line.</p></div>
+<div class="paragraph"><p>Servers MUST terminate the response with the magic <tt>0000</tt> end
+pkt-line marker.</p></div>
+<div class="paragraph"><p>The returned response is a pkt-line stream describing each ref and
+its known value. The stream SHOULD be sorted by name according to
+the C locale ordering. The stream SHOULD include the default ref
+named <tt>HEAD</tt> as the first ref. The stream MUST include capability
+declarations behind a NUL on the first ref.</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>smart_reply = PKT-LINE("# service=$servicename" LF)
+ ref_list
+ "0000"
+ref_list = empty_list / non_empty_list</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>empty_list = PKT-LINE(zero-id SP "capabilities^{}" NUL cap-list LF)</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>non_empty_list = PKT-LINE(obj-id SP name NUL cap_list LF)
+ *ref_record</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>cap-list = capability *(SP capability)
+capability = 1*(LC_ALPHA / DIGIT / "-" / "_")
+LC_ALPHA = %x61-7A</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>ref_record = any_ref / peeled_ref
+any_ref = PKT-LINE(obj-id SP name LF)
+peeled_ref = PKT-LINE(obj-id SP name LF)
+ PKT-LINE(obj-id SP name "^{}" LF</tt></pre>
+</div></div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_smart_service_git_upload_pack">Smart Service git-upload-pack</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>This service reads from the repository pointed to by <tt>$GIT_URL</tt>.</p></div>
+<div class="paragraph"><p>Clients MUST first perform ref discovery with
+<tt>$GIT_URL/info/refs?service=git-upload-pack</tt>.</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>C: POST $GIT_URL/git-upload-pack HTTP/1.0
+C: Content-Type: application/x-git-upload-pack-request
+C:
+C: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7\n
+C: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993\n
+C: 0000</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>S: 200 OK
+S: Content-Type: application/x-git-upload-pack-result
+S: Cache-Control: no-cache
+S:
+S: ....ACK %s, continue
+S: ....NAK</tt></pre>
+</div></div>
+<div class="paragraph"><p>Clients MUST NOT reuse or revalidate a cached response.
+Servers MUST include sufficient Cache-Control headers
+to prevent caching of the response.</p></div>
+<div class="paragraph"><p>Servers SHOULD support all capabilities defined here.</p></div>
+<div class="paragraph"><p>Clients MUST send at least one "want" command in the request body.
+Clients MUST NOT reference an id in a "want" command which did not
+appear in the response obtained through ref discovery unless the
+server advertises capability <tt>allow-tip-sha1-in-want</tt>.</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>compute_request = want_list
+ have_list
+ request_end
+request_end = "0000" / "done"</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>want_list = PKT-LINE(want NUL cap_list LF)
+ *(want_pkt)
+want_pkt = PKT-LINE(want LF)
+want = "want" SP id
+cap_list = *(SP capability) SP</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>have_list = *PKT-LINE("have" SP id LF)</tt></pre>
+</div></div>
+<div class="paragraph"><p>TODO: Document this further.</p></div>
+<div class="sect2">
+<h3 id="_the_negotiation_algorithm">The Negotiation Algorithm</h3>
+<div class="paragraph"><p>The computation to select the minimal pack proceeds as follows
+(C = client, S = server):</p></div>
+<div class="paragraph"><p><em>init step:</em></p></div>
+<div class="paragraph"><p>C: Use ref discovery to obtain the advertised refs.</p></div>
+<div class="paragraph"><p>C: Place any object seen into set <tt>advertised</tt>.</p></div>
+<div class="paragraph"><p>C: Build an empty set, <tt>common</tt>, to hold the objects that are later
+ determined to be on both ends.</p></div>
+<div class="paragraph"><p>C: Build a set, <tt>want</tt>, of the objects from <tt>advertised</tt> the client
+ wants to fetch, based on what it saw during ref discovery.</p></div>
+<div class="paragraph"><p>C: Start a queue, <tt>c_pending</tt>, ordered by commit time (popping newest
+ first). Add all client refs. When a commit is popped from
+ the queue its parents SHOULD be automatically inserted back.
+ Commits MUST only enter the queue once.</p></div>
+<div class="paragraph"><p><em>one compute step:</em></p></div>
+<div class="paragraph"><p>C: Send one <tt>$GIT_URL/git-upload-pack</tt> request:</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>C: 0032want &lt;want #1&gt;...............................
+C: 0032want &lt;want #2&gt;...............................
+....
+C: 0032have &lt;common #1&gt;.............................
+C: 0032have &lt;common #2&gt;.............................
+....
+C: 0032have &lt;have #1&gt;...............................
+C: 0032have &lt;have #2&gt;...............................
+....
+C: 0000</tt></pre>
+</div></div>
+<div class="paragraph"><p>The stream is organized into "commands", with each command
+appearing by itself in a pkt-line. Within a command line
+the text leading up to the first space is the command name,
+and the remainder of the line to the first LF is the value.
+Command lines are terminated with an LF as the last byte of
+the pkt-line value.</p></div>
+<div class="paragraph"><p>Commands MUST appear in the following order, if they appear
+at all in the request stream:</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+"want"
+</p>
+</li>
+<li>
+<p>
+"have"
+</p>
+</li>
+</ul></div>
+<div class="paragraph"><p>The stream is terminated by a pkt-line flush (<tt>0000</tt>).</p></div>
+<div class="paragraph"><p>A single "want" or "have" command MUST have one hex formatted
+SHA-1 as its value. Multiple SHA-1s MUST be sent by sending
+multiple commands.</p></div>
+<div class="paragraph"><p>The <tt>have</tt> list is created by popping the first 32 commits
+from <tt>c_pending</tt>. Less can be supplied if <tt>c_pending</tt> empties.</p></div>
+<div class="paragraph"><p>If the client has sent 256 "have" commits and has not yet
+received one of those back from <tt>s_common</tt>, or the client has
+emptied <tt>c_pending</tt> it SHOULD include a "done" command to let
+the server know it won&#8217;t proceed:</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>C: 0009done</tt></pre>
+</div></div>
+<div class="paragraph"><p>S: Parse the git-upload-pack request:</p></div>
+<div class="paragraph"><p>Verify all objects in <tt>want</tt> are directly reachable from refs.</p></div>
+<div class="paragraph"><p>The server MAY walk backwards through history or through
+the reflog to permit slightly stale requests.</p></div>
+<div class="paragraph"><p>If no "want" objects are received, send an error:
+TODO: Define error if no "want" lines are requested.</p></div>
+<div class="paragraph"><p>If any "want" object is not reachable, send an error:
+TODO: Define error if an invalid "want" is requested.</p></div>
+<div class="paragraph"><p>Create an empty list, <tt>s_common</tt>.</p></div>
+<div class="paragraph"><p>If "have" was sent:</p></div>
+<div class="paragraph"><p>Loop through the objects in the order supplied by the client.</p></div>
+<div class="paragraph"><p>For each object, if the server has the object reachable from
+a ref, add it to <tt>s_common</tt>. If a commit is added to <tt>s_common</tt>,
+do not add any ancestors, even if they also appear in <tt>have</tt>.</p></div>
+<div class="paragraph"><p>S: Send the git-upload-pack response:</p></div>
+<div class="paragraph"><p>If the server has found a closed set of objects to pack or the
+request ends with "done", it replies with the pack.
+TODO: Document the pack based response</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>S: PACK...</tt></pre>
+</div></div>
+<div class="paragraph"><p>The returned stream is the side-band-64k protocol supported
+by the git-upload-pack service, and the pack is embedded into
+stream 1. Progress messages from the server side MAY appear
+in stream 2.</p></div>
+<div class="paragraph"><p>Here a "closed set of objects" is defined to have at least
+one path from every "want" to at least one "common" object.</p></div>
+<div class="paragraph"><p>If the server needs more information, it replies with a
+status continue response:
+TODO: Document the non-pack response</p></div>
+<div class="paragraph"><p>C: Parse the upload-pack response:
+ TODO: Document parsing response</p></div>
+<div class="paragraph"><p><em>Do another compute step.</em></p></div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_smart_service_git_receive_pack">Smart Service git-receive-pack</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>This service reads from the repository pointed to by <tt>$GIT_URL</tt>.</p></div>
+<div class="paragraph"><p>Clients MUST first perform ref discovery with
+<tt>$GIT_URL/info/refs?service=git-receive-pack</tt>.</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>C: POST $GIT_URL/git-receive-pack HTTP/1.0
+C: Content-Type: application/x-git-receive-pack-request
+C:
+C: ....0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0 report-status
+C: 0000
+C: PACK....</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>S: 200 OK
+S: Content-Type: application/x-git-receive-pack-result
+S: Cache-Control: no-cache
+S:
+S: ....</tt></pre>
+</div></div>
+<div class="paragraph"><p>Clients MUST NOT reuse or revalidate a cached response.
+Servers MUST include sufficient Cache-Control headers
+to prevent caching of the response.</p></div>
+<div class="paragraph"><p>Servers SHOULD support all capabilities defined here.</p></div>
+<div class="paragraph"><p>Clients MUST send at least one command in the request body.
+Within the command portion of the request body clients SHOULD send
+the id obtained through ref discovery as old_id.</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>update_request = command_list
+ "PACK" &lt;binary data&gt;</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>command_list = PKT-LINE(command NUL cap_list LF)
+ *(command_pkt)
+command_pkt = PKT-LINE(command LF)
+cap_list = *(SP capability) SP</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>command = create / delete / update
+create = zero-id SP new_id SP name
+delete = old_id SP zero-id SP name
+update = old_id SP new_id SP name</tt></pre>
+</div></div>
+<div class="paragraph"><p>TODO: Document this further.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references">References</h2>
+<div class="sectionbody">
+<div class="paragraph"><p><a href="http://www.ietf.org/rfc/rfc1738.txt">RFC 1738: Uniform Resource Locators (URL)</a>
+<a href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616: Hypertext Transfer Protocol&#8201;&#8212;&#8201;HTTP/1.1</a>
+link:technical/pack-protocol.html
+link:technical/protocol-capabilities.html</p></div>
+</div>
+</div>
+</div>
+<div id="footnotes"><hr /></div>
+<div id="footer">
+<div id="footer-text">
+Last updated 2014-01-27 13:30:07 PST
+</div>
+</div>
+</body>
+</html>
225 technical/http-protocol.txt
View
@@ -20,13 +20,13 @@ URL syntax documented by RFC 1738, so they are of the form:
http://<host>:<port>/<path>?<searchpart>
-Within this documentation the placeholder $GIT_URL will stand for
+Within this documentation the placeholder `$GIT_URL` will stand for
the http:// repository URL entered by the end-user.
-Servers SHOULD handle all requests to locations matching $GIT_URL, as
+Servers SHOULD handle all requests to locations matching `$GIT_URL`, as
both the "smart" and "dumb" HTTP protocols used by Git operate
by appending additional path components onto the end of the user
-supplied $GIT_URL string.
+supplied `$GIT_URL` string.
An example of a dumb client requesting for a loose object:
@@ -43,10 +43,10 @@ An example of a request to a submodule:
$GIT_URL: http://example.com/git/repo.git/path/submodule.git
URL request: http://example.com/git/repo.git/path/submodule.git/info/refs
-Clients MUST strip a trailing '/', if present, from the user supplied
-$GIT_URL string to prevent empty path tokens ('//') from appearing
+Clients MUST strip a trailing `/`, if present, from the user supplied
+`$GIT_URL` string to prevent empty path tokens (`//`) from appearing
in any URL sent to a server. Compatible clients MUST expand
-'$GIT_URL/info/refs' as 'foo/info/refs' and not 'foo//info/refs'.
+`$GIT_URL/info/refs` as `foo/info/refs` and not `foo//info/refs`.
Authentication
@@ -103,14 +103,14 @@ Except where noted, all standard HTTP behavior SHOULD be assumed
by both client and server. This includes (but is not necessarily
limited to):
-If there is no repository at $GIT_URL, or the resource pointed to by a
-location matching $GIT_URL does not exist, the server MUST NOT respond
-with '200 OK' response. A server SHOULD respond with
-'404 Not Found', '410 Gone', or any other suitable HTTP status code
+If there is no repository at `$GIT_URL`, or the resource pointed to by a
+location matching `$GIT_URL` does not exist, the server MUST NOT respond
+with `200 OK` response. A server SHOULD respond with
+`404 Not Found`, `410 Gone`, or any other suitable HTTP status code
which does not imply the resource exists as requested.
-If there is a repository at $GIT_URL, but access is not currently
-permitted, the server MUST respond with the '403 Forbidden' HTTP
+If there is a repository at `$GIT_URL`, but access is not currently
+permitted, the server MUST respond with the `403 Forbidden` HTTP
status code.
Servers SHOULD support both HTTP 1.0 and HTTP 1.1.
@@ -126,9 +126,9 @@ Servers MAY return ETag and/or Last-Modified headers.
Clients MAY revalidate cached entities by including If-Modified-Since
and/or If-None-Match request headers.
-Servers MAY return '304 Not Modified' if the relevant headers appear
+Servers MAY return `304 Not Modified` if the relevant headers appear
in the request and the entity has not changed. Clients MUST treat
-'304 Not Modified' identical to '200 OK' by reusing the cached entity.
+`304 Not Modified` identical to `200 OK` by reusing the cached entity.
Clients MAY reuse a cached entity without revalidation if the
Cache-Control and/or Expires header permits caching. Clients and
@@ -148,7 +148,7 @@ HTTP clients that only support the "dumb" protocol MUST discover
references by making a request for the special info/refs file of
the repository.
-Dumb HTTP clients MUST make a GET request to $GIT_URL/info/refs,
+Dumb HTTP clients MUST make a `GET` request to `$GIT_URL/info/refs`,
without any search/query parameters.
C: GET $GIT_URL/info/refs HTTP/1.0
@@ -161,21 +161,21 @@ without any search/query parameters.
S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
The Content-Type of the returned info/refs entity SHOULD be
-"text/plain; charset=utf-8", but MAY be any content type.
+`text/plain; charset=utf-8`, but MAY be any content type.
Clients MUST NOT attempt to validate the returned Content-Type.
Dumb servers MUST NOT return a return type starting with
-"application/x-git-".
+`application/x-git-`.
Cache-Control headers MAY be returned to disable caching of the
returned entity.
When examining the response clients SHOULD only examine the HTTP
-status code. Valid responses are '200 OK', or '304 Not Modified'.
+status code. Valid responses are `200 OK`, or `304 Not Modified`.
The returned content is a UNIX formatted text file describing
each ref and its known value. The file SHOULD be sorted by name
according to the C locale ordering. The file SHOULD NOT include
-the default ref named 'HEAD'.
+the default ref named `HEAD`.
info_refs = *( ref_record )
ref_record = any_ref / peeled_ref
@@ -192,13 +192,14 @@ HTTP clients that support the "smart" protocol (or both the
a parameterized request for the info/refs file of the repository.
The request MUST contain exactly one query parameter,
-'service=$servicename', where $servicename MUST be the service
+`service=$servicename`, where `$servicename` MUST be the service
name the client wishes to contact to complete the operation.
The request MUST NOT contain additional query parameters.
C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
- dumb server reply:
+dumb server reply:
+
S: 200 OK
S:
S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
@@ -206,7 +207,8 @@ The request MUST NOT contain additional query parameters.
S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
- smart server reply:
+smart server reply:
+
S: 200 OK
S: Content-Type: application/x-git-upload-pack-advertisement
S: Cache-Control: no-cache
@@ -228,7 +230,7 @@ Smart Server Response
^^^^^^^^^^^^^^^^^^^^^
If the server does not recognize the requested service name, or the
requested service name has been disabled by the server administrator,
-the server MUST respond with the '403 Forbidden' HTTP status code.
+the server MUST respond with the `403 Forbidden` HTTP status code.
Otherwise, smart servers MUST respond with the smart server reply
format for the requested service name.
@@ -236,35 +238,35 @@ format for the requested service name.
Cache-Control headers SHOULD be used to disable caching of the
returned entity.
-The Content-Type MUST be 'application/x-$servicename-advertisement'.
+The Content-Type MUST be `application/x-$servicename-advertisement`.
Clients SHOULD fall back to the dumb protocol if another content
type is returned. When falling back to the dumb protocol clients
-SHOULD NOT make an additional request to $GIT_URL/info/refs, but
+SHOULD NOT make an additional request to `$GIT_URL/info/refs`, but
instead SHOULD use the response already in hand. Clients MUST NOT
continue if they do not support the dumb protocol.
-Clients MUST validate the status code is either '200 OK' or
-'304 Not Modified'.
+Clients MUST validate the status code is either `200 OK` or
+`304 Not Modified`.
Clients MUST validate the first five bytes of the response entity
-matches the regex "^[0-9a-f]{4}#". If this test fails, clients
+matches the regex `^[0-9a-f]{4}#`. If this test fails, clients
MUST NOT continue.
Clients MUST parse the entire response as a sequence of pkt-line
records.
-Clients MUST verify the first pkt-line is "# service=$servicename".
+Clients MUST verify the first pkt-line is `# service=$servicename`.
Servers MUST set $servicename to be the request parameter value.
Servers SHOULD include an LF at the end of this line.
Clients MUST ignore an LF at the end of the line.
-Servers MUST terminate the response with the magic "0000" end
+Servers MUST terminate the response with the magic `0000` end
pkt-line marker.
The returned response is a pkt-line stream describing each ref and
its known value. The stream SHOULD be sorted by name according to
the C locale ordering. The stream SHOULD include the default ref
-named 'HEAD' as the first ref. The stream MUST include capability
+named `HEAD` as the first ref. The stream MUST include capability
declarations behind a NUL on the first ref.
smart_reply = PKT-LINE("# service=$servicename" LF)
@@ -286,12 +288,13 @@ declarations behind a NUL on the first ref.
peeled_ref = PKT-LINE(obj-id SP name LF)
PKT-LINE(obj-id SP name "^{}" LF
+
Smart Service git-upload-pack
------------------------------
-This service reads from the repository pointed to by $GIT_URL.
+This service reads from the repository pointed to by `$GIT_URL`.
Clients MUST first perform ref discovery with
-'$GIT_URL/info/refs?service=git-upload-pack'.
+`$GIT_URL/info/refs?service=git-upload-pack`.
C: POST $GIT_URL/git-upload-pack HTTP/1.0
C: Content-Type: application/x-git-upload-pack-request
@@ -313,10 +316,10 @@ to prevent caching of the response.
Servers SHOULD support all capabilities defined here.
-Clients MUST send at least one 'want' command in the request body.
-Clients MUST NOT reference an id in a 'want' command which did not
+Clients MUST send at least one "want" command in the request body.
+Clients MUST NOT reference an id in a "want" command which did not
appear in the response obtained through ref discovery unless the
-server advertises capability "allow-tip-sha1-in-want".
+server advertises capability `allow-tip-sha1-in-want`.
compute_request = want_list
have_list
@@ -332,128 +335,128 @@ server advertises capability "allow-tip-sha1-in-want".
<