summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/Makefile10
-rw-r--r--Documentation/RelNotes/1.9.txt46
-rw-r--r--Documentation/git-checkout.txt4
-rw-r--r--Documentation/git-column.txt5
-rw-r--r--Documentation/git-for-each-ref.txt10
-rw-r--r--Documentation/git-http-backend.txt8
-rw-r--r--Documentation/git-notes.txt10
-rw-r--r--Documentation/git-p4.txt6
-rw-r--r--Documentation/git-pull.txt4
-rw-r--r--Documentation/git-remote-ext.txt5
-rw-r--r--Documentation/git-remote-fd.txt4
-rw-r--r--Documentation/git-show-ref.txt1
-rw-r--r--Documentation/gitattributes.txt9
-rw-r--r--Documentation/gitignore.txt2
-rw-r--r--Documentation/gitk.txt16
-rw-r--r--Documentation/merge-options.txt9
-rw-r--r--Documentation/revisions.txt2
-rw-r--r--Documentation/technical/http-protocol.txt225
18 files changed, 209 insertions, 167 deletions
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 36c58fc646..fc6b2cf9ec 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -2,6 +2,9 @@
MAN1_TXT =
MAN5_TXT =
MAN7_TXT =
+TECH_DOCS =
+ARTICLES =
+SP_ARTICLES =
MAN1_TXT += $(filter-out \
$(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
@@ -37,12 +40,12 @@ MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT))
OBSOLETE_HTML = git-remote-helpers.html
DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML)
-ARTICLES = howto-index
+ARTICLES += howto-index
ARTICLES += everyday
ARTICLES += git-tools
ARTICLES += git-bisect-lk2009
# with their own formatting rules.
-SP_ARTICLES = user-manual
+SP_ARTICLES += user-manual
SP_ARTICLES += howto/new-command
SP_ARTICLES += howto/revert-branch-rebase
SP_ARTICLES += howto/using-merge-subtree
@@ -60,7 +63,8 @@ SP_ARTICLES += howto/maintain-git
API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
SP_ARTICLES += $(API_DOCS)
-TECH_DOCS = technical/index-format
+TECH_DOCS += technical/http-protocol
+TECH_DOCS += technical/index-format
TECH_DOCS += technical/pack-format
TECH_DOCS += technical/pack-heuristics
TECH_DOCS += technical/pack-protocol
diff --git a/Documentation/RelNotes/1.9.txt b/Documentation/RelNotes/1.9.txt
index 7bcf371c5f..43c7b682a6 100644
--- a/Documentation/RelNotes/1.9.txt
+++ b/Documentation/RelNotes/1.9.txt
@@ -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.
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 91294f89c8..33ad2adf5c 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -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
diff --git a/Documentation/git-column.txt b/Documentation/git-column.txt
index 5d6f1cc464..03d18465d4 100644
--- a/Documentation/git-column.txt
+++ b/Documentation/git-column.txt
@@ -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
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 94f5c465da..42408752d0 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -219,13 +219,9 @@ 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]
GIT
---
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index e3bcdb50e3..e8c13f60ae 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -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
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index 46ef0466be..84bb0fecb0 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -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
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 8cba16d67f..6ab5f9497a 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -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.
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 6083aab87b..200eb22260 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -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
diff --git a/Documentation/git-remote-ext.txt b/Documentation/git-remote-ext.txt
index 8cfc748ae2..cd0bb77e4a 100644
--- a/Documentation/git-remote-ext.txt
+++ b/Documentation/git-remote-ext.txt
@@ -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
diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt
index 933c2adaf6..bcd37668e3 100644
--- a/Documentation/git-remote-fd.txt
+++ b/Documentation/git-remote-fd.txt
@@ -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
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index b0a309b117..ffd1b03a9c 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -175,6 +175,7 @@ FILES
SEE ALSO
--------
+linkgit:git-for-each-ref[1],
linkgit:git-ls-remote[1],
linkgit:git-update-ref[1],
linkgit:gitrepository-layout[5]
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index b322a2666c..643c1ba929 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -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
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 205e80ef88..b08d34d84e 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -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
-----------
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index d44e14c138..1e9e38ae40 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -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
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index afba8d4f3b..e1343155fa 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -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
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 2c06ed34ad..5a286d0d61 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -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\}'::
diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt
index d21d77d1de..544373b16f 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -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".
have_list = *PKT-LINE("have" SP id LF)
TODO: Document this further.
-TODO: Don't use uppercase for variable names below.
The Negotiation Algorithm
~~~~~~~~~~~~~~~~~~~~~~~~~
The computation to select the minimal pack proceeds as follows
-(c = client, s = server):
+(C = client, S = server):
+
+'init step:'
+
+C: Use ref discovery to obtain the advertised refs.
+
+C: Place any object seen into set `advertised`.
- init step:
- (c) Use ref discovery to obtain the advertised refs.
- (c) Place any object seen into set ADVERTISED.
+C: Build an empty set, `common`, to hold the objects that are later
+ determined to be on both ends.
- (c) Build an empty set, COMMON, to hold the objects that are later
- determined to be on both ends.
- (c) Build a set, WANT, of the objects from ADVERTISED the client
- wants to fetch, based on what it saw during ref discovery.
+C: Build a set, `want`, of the objects from `advertised` the client
+ wants to fetch, based on what it saw during ref discovery.
- (c) Start a queue, C_PENDING, 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.
+C: Start a queue, `c_pending`, 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.
- one compute step:
- (c) Send one $GIT_URL/git-upload-pack request:
+'one compute step:'
- C: 0032want <WANT #1>...............................
- C: 0032want <WANT #2>...............................
+C: Send one `$GIT_URL/git-upload-pack` request:
+
+ C: 0032want <want #1>...............................
+ C: 0032want <want #2>...............................
....
- C: 0032have <COMMON #1>.............................
- C: 0032have <COMMON #2>.............................
+ C: 0032have <common #1>.............................
+ C: 0032have <common #2>.............................
....
- C: 0032have <HAVE #1>...............................
- C: 0032have <HAVE #2>...............................
+ C: 0032have <have #1>...............................
+ C: 0032have <have #2>...............................
....
C: 0000
- 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.
+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.
- Commands MUST appear in the following order, if they appear
- at all in the request stream:
+Commands MUST appear in the following order, if they appear
+at all in the request stream:
- * want
- * have
+* "want"
+* "have"
- The stream is terminated by a pkt-line flush ("0000").
+The stream is terminated by a pkt-line flush (`0000`).
- 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.
+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.
- The HAVE list is created by popping the first 32 commits
- from C_PENDING. Less can be supplied if C_PENDING empties.
+The `have` list is created by popping the first 32 commits
+from `c_pending`. Less can be supplied if `c_pending` empties.
- If the client has sent 256 HAVE commits and has not yet
- received one of those back from S_COMMON, or the client has
- emptied C_PENDING it SHOULD include a "done" command to let
- the server know it won't proceed:
+If the client has sent 256 "have" commits and has not yet
+received one of those back from `s_common`, or the client has
+emptied `c_pending` it SHOULD include a "done" command to let
+the server know it won't proceed:
C: 0009done
- (s) Parse the git-upload-pack request:
-
- Verify all objects in WANT are directly reachable from refs.
-
- The server MAY walk backwards through history or through
- the reflog to permit slightly stale requests.
+S: Parse the git-upload-pack request:
- If no WANT objects are received, send an error:
+Verify all objects in `want` are directly reachable from refs.
-TODO: Define error if no want lines are requested.
+The server MAY walk backwards through history or through
+the reflog to permit slightly stale requests.
- If any WANT object is not reachable, send an error:
+If no "want" objects are received, send an error:
+TODO: Define error if no "want" lines are requested.
-TODO: Define error if an invalid want is requested.
+If any "want" object is not reachable, send an error:
+TODO: Define error if an invalid "want" is requested.
- Create an empty list, S_COMMON.
+Create an empty list, `s_common`.
- If 'have' was sent:
+If "have" was sent:
- Loop through the objects in the order supplied by the client.
- For each object, if the server has the object reachable from
- a ref, add it to S_COMMON. If a commit is added to S_COMMON,
- do not add any ancestors, even if they also appear in HAVE.
+Loop through the objects in the order supplied by the client.
- (s) Send the git-upload-pack response:
+For each object, if the server has the object reachable from
+a ref, add it to `s_common`. If a commit is added to `s_common`,
+do not add any ancestors, even if they also appear in `have`.
- If the server has found a closed set of objects to pack or the
- request ends with "done", it replies with the pack.
+S: Send the git-upload-pack response:
+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
- S: PACK...
- 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.
+ S: PACK...
- Here a "closed set of objects" is defined to have at least
- one path from every WANT to at least one COMMON object.
+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.
- If the server needs more information, it replies with a
- status continue response:
+Here a "closed set of objects" is defined to have at least
+one path from every "want" to at least one "common" object.
+If the server needs more information, it replies with a
+status continue response:
TODO: Document the non-pack response
- (c) Parse the upload-pack response:
-
-TODO: Document parsing response
+C: Parse the upload-pack response:
+ TODO: Document parsing response
- Do another compute step.
+'Do another compute step.'
Smart Service git-receive-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-receive-pack'.
+`$GIT_URL/info/refs?service=git-receive-pack`.
C: POST $GIT_URL/git-receive-pack HTTP/1.0
C: Content-Type: application/x-git-receive-pack-request