{"thread":{"id":"39226","subject":"[Patch] Added http-protocol for git in the Documentation folder","startedAt":"2015-05-03T16:18:15Z","lastAt":"2015-05-03T17:56:52Z","messageCount":5,"participants":["Alangi Derick","Karthik Nayak","Eric Sunshine","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"260466","messageId":"CAKB+oNsPzoBRUn6rD3Bb8soHEub3quT76MB25KyWfcEC1smdJg@mail.gmail.com","threadId":"39226","inReplyTo":null,"subject":"[Patch] Added http-protocol for git in the Documentation folder","fromName":"Alangi Derick","fromEmail":"alangiderick@gmail.com","sentAt":"2015-05-03T16:18:15Z","receivedAt":"2015-05-03T16:18:15Z","isPatch":true,"sender":{"key":"alangiderick@gmail.com","avatar":"https://gravatar.com/avatar/f5878e69e83b4cf7ed499336c4a114dc2cb253253bc57c9b8ffcf0e129320795?d=mp&s=160"},"body":"This patch is to include the http-protocol in the documentations\nfolder as stated by the left over projects here:\nhttp://git-blame.blogspot.de/p/leftover-bits.html.\nI got the documentation uploaded by Scott in his drop box some years ago.\nhttps://www.dropbox.com/s/pwawp8kmwgyc3w2/http-protocol.txt\n\nSorry my git send-email is not working that is why i sent the patch as\nan attachment, so it can be applied.\n\nRegards\nAlangi Derick Ndimnain\n\n\nFrom 0595060d83c556cb7a8fca21bede65ca4b9e9023 Mon Sep 17 00:00:00 2001\nFrom: Alangi Derick \nDate: Sun, 3 May 2015 17:09:58 +0100\nSubject: [PATCH] Added the http-protocol for git in the set of documentation\n files\n\nSigned-off-by: Alangi Derick \n---\n Documentation/http-protocol.txt | 541 ++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 541 insertions(+)\n create mode 100644 Documentation/http-protocol.txt\n\ndiff --git a/Documentation/http-protocol.txt b/Documentation/http-protocol.txt\nnew file mode 100644\nindex 0000000..0848dc3\n--- /dev/null\n+++ b/Documentation/http-protocol.txt\n@@ -0,0 +1,541 @@\n+HTTP transfer protocols\n+=======================\n+\n+Git supports two HTTP based transfer protocols. A \"dumb\" protocol\n+which requires only a standard HTTP server on the server end of the\n+connection, and a \"smart\" protocol which requires a Git aware CGI\n+(or server module). This document describes both protocols.\n+\n+As a design feature smart clients can automatically upgrade \"dumb\"\n+protocol URLs to smart URLs. This permits all users to have the\n+same published URL, and the peers automatically select the most\n+efficient transport available to them.\n+\n+\n+URL Format\n+----------\n+\n+URLs for Git repositories accessed by HTTP use the standard HTTP\n+URL syntax documented by RFC 1738, so they are of the form:\n+\n+ http://:/\n+\n+Within this documentation the placeholder $GIT_URL will stand for\n+the http:// repository URL entered by the end-user.\n+\n+Both the \"smart\" and \"dumb\" HTTP protocols used by Git operate\n+by appending additional path components onto the end of the user\n+supplied $GIT_URL string.\n+\n+Clients MUST strip a trailing '/', if present, from the user supplied\n+$GIT_URL string to prevent empty path tokens ('//') from appearing\n+in any URL sent to a server. Compatible clients must expand\n+'$GIT_URL/info/refs' as 'foo/info/refs' and not 'foo//info/refs'.\n+\n+\n+Authentication\n+--------------\n+\n+Standard HTTP authentication is used if authentication is required\n+to access a repository, and MAY be configured and enforced by the\n+HTTP server software.\n+\n+Because Git repositories are accessed by standard path components\n+server administrators MAY use directory based permissions within\n+their HTTP server to control repository access.\n+\n+Clients SHOULD support Basic authentication as described by RFC 2616.\n+Servers SHOULD support Basic authentication by relying upon the\n+HTTP server placed in front of the Git server software.\n+\n+Servers MUST NOT require HTTP cookies for the purposes of\n+authentication or access control.\n+\n+Clients and servers MAY support other common forms of HTTP based\n+authentication, such as Digest authentication.\n+\n+\n+SSL\n+---\n+\n+Clients and servers SHOULD support SSL, particularly to protect\n+passwords when relying on Basic HTTP authentication.\n+\n+\n+Session State\n+-------------\n+\n+The Git over HTTP protocol (much like HTTP itself) is stateless\n+from the perspective of the HTTP server side. All state must be\n+retained and managed by the client process. This permits simple\n+round-robin load-balancing on the server side, without needing to\n+worry about state mangement.\n+\n+Clients MUST NOT require state management on the server side in\n+order to function correctly.\n+\n+Servers MUST NOT require HTTP cookies in order to function correctly.\n+Clients MAY store and forward HTTP cookies during request processing\n+as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore any\n+cookies sent by a client.\n+\n+\n+pkt-line Format\n+---------------\n+\n+Much (but not all) of the payload is described around pkt-lines.\n+\n+A pkt-line is a variable length binary string. The first four bytes\n+of the line indicates the total length of the line, in hexadecimal.\n+The total length includes the 4 bytes used to denote the length.\n+A line SHOULD BE terminated by an LF, which if present MUST be\n+included in the total length.\n+\n+A pkt-line MAY contain binary data, so implementors MUST ensure all\n+pkt-line parsing/formatting routines are 8-bit clean. The maximum\n+length of a pkt-line's data is 65532 bytes (65536 - 4).\n+\n+Examples (as C-style strings):\n+\n+ pkt-line actual value\n+ ---------------------------------\n+ \"0006a\\n\" \"a\\n\"\n+ \"0005a\" \"a\"\n+ \"000bfoobar\\n\" \"foobar\\n\"\n+ \"0004\" \"\"\n+\n+A pkt-line with a length of 0 (\"0000\") is a special case and MUST\n+be treated as a message break or terminator in the payload.\n+\n+\n+General Request Processing\n+--------------------------\n+\n+Except where noted, all standard HTTP behavior SHOULD be assumed\n+by both client and server. This includes (but is not necessarily\n+limited to):\n+\n+If there is no repository at $GIT_URL, the server MUST respond with\n+the '404 Not Found' HTTP status code.\n+\n+If there is a repository at $GIT_URL, but access is not currently\n+permitted, the server MUST respond with the '403 Forbidden' HTTP\n+status code.\n+\n+Servers SHOULD support both HTTP 1.0 and HTTP 1.1.\n+Servers SHOULD support chunked encoding for both\n+request and response bodies.\n+\n+Clients SHOULD support both HTTP 1.0 and HTTP 1.1.\n+Clients SHOULD support chunked encoding for both\n+request and response bodies.\n+\n+Servers MAY return ETag and/or Last-Modified headers.\n+\n+Clients MAY revalidate cached entities by including If-Modified-Since\n+and/or If-None-Match request headers.\n+\n+Servers MAY return '304 Not Modified' if the relevant headers appear\n+in the request and the entity has not changed. Clients MUST treat\n+'304 Not Modified' identical to '200 OK' by reusing the cached entity.\n+\n+Clients MAY reuse a cached entity without revalidation if the\n+Cache-Control and/or Expires header permits caching. Clients and\n+servers MUST follow RFC 2616 for cache controls.\n+\n+\n+Discovering References\n+----------------------\n+\n+All HTTP clients MUST begin either a fetch or a push exchange by\n+discovering the references available on the remote repository.\n+\n+Dumb Clients\n+~~~~~~~~~~~~\n+\n+HTTP clients that only support the \"dumb\" protocol MUST discover\n+references by making a request for the special info/refs file of\n+the repository.\n+\n+Dumb HTTP clients MUST NOT include search/query parameters when\n+fetching the info/refs file. (That is, '?' must not appear in the\n+requested URL.)\n+\n+\tC: GET $GIT_URL/info/refs HTTP/1.0\n+\n+\tS: 200 OK\n+\tS:\n+\tS: 95dcfa3633004da0049d3d0fa03f80589cbcaf31\trefs/heads/maint\n+\tS: d049f6c27a2244e12041955e262a404c7faba355\trefs/heads/master\n+\tS: 2cb58b79488a98d2721cea644875a8dd0026b115\trefs/tags/v1.0\n+\tS: a3c2e2402b99163d1d59756e5f207ae21cccba4c\trefs/tags/v1.0^{}\n+\n+The Content-Type of the returned info/refs entity SHOULD be\n+\"text/plain; charset=utf-8\", but MAY be any content type.\n+Clients MUST NOT attempt to validate the returned Content-Type.\n+Dumb servers MUST NOT return a return type starting with\n+\"application/x-git-\".\n+\n+Cache-Control headers MAY be returned to disable caching of the\n+returned entity.\n+\n+When examining the response clients SHOULD only examine the HTTP\n+status code. Valid responses are '200 OK', or '304 Not Modified'.\n+\n+The returned content is a UNIX formatted text file describing\n+each ref and its known value. The file SHOULD be sorted by name\n+according to the C locale ordering. The file SHOULD NOT include\n+the default ref named 'HEAD'.\n+\n+\tinfo_refs = *( ref_record )\n+\tref_record = any_ref | peeled_ref\n+\n+\tany_ref = id HT name LF\n+\tpeeled_ref = id HT name LF\n+\t id HT name \"^{}\" LF\n+\tid = 40*HEX\n+\n+\tHEX = \"0\"..\"9\" | \"a\"..\"f\"\n+\tLF = \n+\tHT = \n+\n+Smart Clients\n+~~~~~~~~~~~~~\n+\n+HTTP clients that support the \"smart\" protocol (or both the\n+\"smart\" and \"dumb\" protocols) MUST discover references by making\n+a paramterized request for the info/refs file of the repository.\n+\n+The request MUST contain exactly one query parameter,\n+'service=$servicename', where $servicename MUST be the service\n+name the client wishes to contact to complete the operation.\n+The request MUST NOT contain additional query parameters.\n+\n+\tC: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0\n+\n+\tdumb server reply:\n+\tS: 200 OK\n+\tS:\n+\tS: 95dcfa3633004da0049d3d0fa03f80589cbcaf31\trefs/heads/maint\n+\tS: d049f6c27a2244e12041955e262a404c7faba355\trefs/heads/master\n+\tS: 2cb58b79488a98d2721cea644875a8dd0026b115\trefs/tags/v1.0\n+\tS: a3c2e2402b99163d1d59756e5f207ae21cccba4c\trefs/tags/v1.0^{}\n+\n+\tsmart server reply:\n+\tS: 200 OK\n+\tS: Content-Type: application/x-git-upload-pack-advertisement\n+\tS: Cache-Control: no-cache\n+\tS:\n+\tS: ....# service=git-upload-pack\n+\tS: ....95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\\0 multi_ack\n+\tS: ....d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n+\tS: ....2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n+\tS: ....a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n+\n+Dumb Server Response\n+^^^^^^^^^^^^^^^^^^^^\n+Dumb servers MUST respond with the dumb server reply format.\n+\n+See the prior section under dumb clients for a more detailed\n+description of the dumb server response.\n+\n+Smart Server Response\n+^^^^^^^^^^^^^^^^^^^^^\n+Smart servers MUST respond with the smart server reply format.\n+\n+If the server does not recognize the requested service name, or the\n+requested service name has been disabled by the server administrator,\n+the server MUST respond with the '403 Forbidden' HTTP status code.\n+\n+Cache-Control headers SHOULD be used to disable caching of the\n+returned entity.\n+\n+The Content-Type MUST be 'application/x-$servicename-advertisement'.\n+Clients SHOULD fall back to the dumb protocol if another content\n+type is returned. When falling back to the dumb protocol clients\n+SHOULD NOT make an additional request to $GIT_URL/info/refs, but\n+instead SHOULD use the response already in hand. Clients MUST NOT\n+continue if they do not support the dumb protocol.\n+\n+Clients MUST validate the status code is either '200 OK' or\n+'304 Not Modified'.\n+\n+Clients MUST validate the first five bytes of the response entity\n+matches the regex \"^[0-9a-f]{4}#\". If this test fails, clients\n+MUST NOT continue.\n+\n+Clients MUST parse the entire response as a sequence of pkt-line\n+records.\n+\n+Clients MUST verify the first pkt-line is \"# service=$servicename\".\n+Servers MUST set $servicename to be the request parameter value.\n+Servers SHOULD include an LF at the end of this line.\n+Clients MUST ignore an LF at the end of the line.\n+\n+Servers MUST terminate the response with the magic \"0000\" end\n+pkt-line marker.\n+\n+The returned response is a pkt-line stream describing each ref and\n+its known value. The stream SHOULD be sorted by name according to\n+the C locale ordering. The stream SHOULD include the default ref\n+named 'HEAD' as the first ref. The stream MUST include capability\n+declarations behind a NUL on the first ref.\n+\n+\tsmart_reply = PKT-LINE(\"# service=$servicename\" LF)\n+\t ref_list\n+\t \"0000\"\n+\tref_list = empty_list | populated_list\n+\n+\tempty_list = PKT-LINE(id SP \"capabilities^{}\" NUL cap_list LF)\n+\n+\tnon_empty_list = PKT-LINE(id SP name NUL cap_list LF)\n+\t *ref_record\n+\n+\tcap_list = *(SP capability) SP\n+\tref_record = any_ref | peeled_ref\n+\n+\tany_ref = PKT-LINE(id SP name LF)\n+\tpeeled_ref = PKT-LINE(id SP name LF)\n+\t PKT-LINE(id SP name \"^{}\" LF\n+\tid = 40*HEX\n+\n+\tHEX = \"0\"..\"9\" | \"a\"..\"f\"\n+\tNL = \n+\tLF = \n+\tSP = \n+\n+\n+Smart Service git-upload-pack\n+------------------------------\n+This service reads from the remote repository.\n+\n+Clients MUST first perform ref discovery with\n+'$GIT_URL/info/refs?service=git-upload-pack'.\n+\n+\tC: POST $GIT_URL/git-upload-pack HTTP/1.0\n+\tC: Content-Type: application/x-git-upload-pack-request\n+\tC:\n+\tC: ....want 0a53e9ddeaddad63ad106860237bbf53411d11a7\n+\tC: ....have 441b40d833fdfa93eb2908e52742248faf0ee993\n+\tC: 0000\n+\n+\tS: 200 OK\n+\tS: Content-Type: application/x-git-upload-pack-result\n+\tS: Cache-Control: no-cache\n+\tS:\n+\tS: ....ACK %s, continue\n+\tS: ....NAK\n+\n+Clients MUST NOT reuse or revalidate a cached reponse.\n+Servers MUST include sufficient Cache-Control headers\n+to prevent caching of the response.\n+\n+Servers SHOULD support all capabilities defined here.\n+\n+Clients MUST send at least one 'want' command in the request body.\n+Clients MUST NOT reference an id in a 'want' command which did not\n+appear in the response obtained through ref discovery.\n+\n+\tcompute_request = want_list\n+\t have_list\n+\t request_end\n+\trequest_end = \"0000\" | \"done\"\n+\n+\twant_list = PKT-LINE(want NUL cap_list LF)\n+\t *(want_pkt)\n+\twant_pkt = PKT-LINE(want LF)\n+\twant = \"want\" SP id\n+\tcap_list = *(SP capability) SP\n+\n+\thave_list = *PKT-LINE(\"have\" SP id LF)\n+\n+\tcommand = create | delete | update\n+\tcreate = 40*\"0\" SP new_id SP name\n+\tdelete = old_id SP 40*\"0\" SP name\n+\tupdate = old_id SP new_id SP name\n+\n+TODO: Document this further.\n+TODO: Don't use uppercase for variable names below.\n+\n+Capability include-tag\n+~~~~~~~~~~~~~~~~~~~~~~\n+\n+When packing an object that an annotated tag points at, include the\n+tag object too. Clients can request this if they want to fetch\n+tags, but don't know which tags they will need until after they\n+receive the branch data. By enabling include-tag an entire call\n+to upload-pack can be avoided.\n+\n+Capability thin-pack\n+~~~~~~~~~~~~~~~~~~~~\n+\n+When packing a deltified object the base is not included if the base\n+is reachable from an object listed in the COMMON set by the client.\n+This reduces the bandwidth required to transfer, but it does slightly\n+increase processing time for the client to save the pack to disk.\n+\n+The Negotiation Algorithm\n+~~~~~~~~~~~~~~~~~~~~~~~~~\n+The computation to select the minimal pack proceeds as follows\n+(c = client, s = server):\n+\n+ init step:\n+ (c) Use ref discovery to obtain the advertised refs.\n+ (c) Place any object seen into set ADVERTISED.\n+\n+ (c) Build an empty set, COMMON, to hold the objects that are later\n+ determined to be on both ends.\n+ (c) Build a set, WANT, of the objects from ADVERTISED the client\n+ wants to fetch, based on what it saw during ref discovery.\n+\n+ (c) Start a queue, C_PENDING, ordered by commit time (popping newest\n+ first). Add all client refs. When a commit is popped from\n+ the queue its parents should be automatically inserted back.\n+ Commits MUST only enter the queue once.\n+\n+ one compute step:\n+ (c) Send one $GIT_URL/git-upload-pack request:\n+\n+\tC: 0032want ...............................\n+\tC: 0032want ...............................\n+\t....\n+\tC: 0032have .............................\n+\tC: 0032have .............................\n+\t....\n+\tC: 0032have ...............................\n+\tC: 0032have ...............................\n+\t....\n+\tC: 0000\n+\n+ The stream is organized into \"commands\", with each command\n+ appearing by itself in a pkt-line. Within a command line\n+ the text leading up to the first space is the command name,\n+ and the remainder of the line to the first LF is the value.\n+ Command lines are terminated with an LF as the last byte of\n+ the pkt-line value.\n+\n+ Commands MUST appear in the following order, if they appear\n+ at all in the request stream:\n+\n+ * want\n+ * have\n+\n+ The stream is terminated by a pkt-line flush (\"0000\").\n+\n+ A single \"want\" or \"have\" command MUST have one hex formatted\n+ SHA-1 as its value. Multiple SHA-1s MUST be sent by sending\n+ multiple commands.\n+\n+ The HAVE list is created by popping the first 32 commits\n+ from C_PENDING. Less can be supplied if C_PENDING empties.\n+\n+ If the client has sent 256 HAVE commits and has not yet\n+ received one of those back from S_COMMON, or the client has\n+ emptied C_PENDING it should include a \"done\" command to let\n+ the server know it won't proceed:\n+\n+\tC: 0009done\n+\n+ (s) Parse the git-upload-pack request:\n+\n+ Verify all objects in WANT are directly reachable from refs.\n+\n+\t The server MAY walk backwards through history or through\n+ the reflog to permit slightly stale requests.\n+\n+ If no WANT objects are received, send an error:\n+\n+TODO: Define error if no want lines are requested.\n+\n+ If any WANT object is not reachable, send an error:\n+\n+TODO: Define error if an invalid want is requested.\n+\n+ Create an empty list, S_COMMON.\n+\n+ If 'have' was sent:\n+\n+ Loop through the objects in the order supplied by the client.\n+ For each object, if the server has the object reachable from\n+ a ref, add it to S_COMMON. If a commit is added to S_COMMON,\n+ do not add any ancestors, even if they also appear in HAVE.\n+\n+ (s) Send the git-upload-pack response:\n+\n+ If the server has found a closed set of objects to pack or the\n+ request ends with \"done\", it replies with the pack.\n+\n+TODO: Document the pack based response\n+\tS: PACK...\n+\n+ The returned stream is the side-band-64k protocol supported\n+ by the git-upload-pack service, and the pack is embedded into\n+ stream 1. Progress messages from the server side may appear\n+ in stream 2.\n+\n+ Here a \"closed set of objects\" is defined to have at least\n+ one path from every WANT to at least one COMMON object.\n+\n+ If the server needs more information, it replies with a\n+ status continue response:\n+\n+TODO: Document the non-pack response\n+\n+ (c) Parse the upload-pack response:\n+\n+TODO: Document parsing response\n+\n+ Do another compute step.\n+\n+\n+Smart Service git-receive-pack\n+------------------------------\n+This service modifies the remote repository.\n+\n+Clients MUST first perform ref discovery with\n+'$GIT_URL/info/refs?service=git-receive-pack'.\n+\n+\tC: POST $GIT_URL/git-receive-pack HTTP/1.0\n+\tC: Content-Type: application/x-git-receive-pack-request\n+\tC:\n+\tC: ....0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\\0 report-status\n+\tC: 0000\n+\tC: PACK....\n+\n+\tS: 200 OK\n+\tS: Content-Type: application/x-git-receive-pack-result\n+\tS: Cache-Control: no-cache\n+\tS:\n+\tS: ....\n+\n+Clients MUST NOT reuse or revalidate a cached reponse.\n+Servers MUST include sufficient Cache-Control headers\n+to prevent caching of the response.\n+\n+Servers SHOULD support all capabilities defined here.\n+\n+Clients MUST send at least one command in the request body.\n+Within the command portion of the request body clients SHOULD send\n+the id obtained through ref discovery as old_id.\n+\n+\tupdate_request = command_list\n+\t \"PACK\" \n+\n+\tcommand_list = PKT-LINE(command NUL cap_list LF)\n+\t *(command_pkt)\n+\tcommand_pkt = PKT-LINE(command LF)\n+\tcap_list = *(SP capability) SP\n+\n+\tcommand = create | delete | update\n+\tcreate = 40*\"0\" SP new_id SP name\n+\tdelete = old_id SP 40*\"0\" SP name\n+\tupdate = old_id SP new_id SP name\n+\n+TODO: Document this further.\n+\n+\n+References\n+----------\n+\n+link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)]\n+link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1]\n-- \n2.4.0.1.g88b8adf\n\n"},{"id":"260469","messageId":"5832C62F-D7AF-4597-9DBF-FA6DBDDBA99D@gmail.com","threadId":"39226","inReplyTo":"CAKB+oNsPzoBRUn6rD3Bb8soHEub3quT76MB25KyWfcEC1smdJg@mail.gmail.com","subject":"Re: [Patch] Added http-protocol for git in the Documentation folder","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2015-05-03T16:52:41Z","receivedAt":"2015-05-03T16:52:41Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"\n\nOn May 3, 2015 9:48:15 PM GMT+05:30, Alangi Derick wrote:\n>This patch is to include the http-protocol in the documentations\n>folder as stated by the left over projects here:\n>http://git-blame.blogspot.de/p/leftover-bits.html.\n>I got the documentation uploaded by Scott in his drop box some years\n>ago.\n>https://www.dropbox.com/s/pwawp8kmwgyc3w2/http-protocol.txt\n>\n>Sorry my git send-email is not working that is why i sent the patch as\n>an attachment, so it can be applied.\nWhat do you mean by \"git send-email is not working\".\n>\n>Regards\n>Alangi Derick Ndimnain\n"},{"id":"260470","messageId":"CAPig+cSJWdrS-bBXcHE5ZmpZ3Aj8tKehXgFan6=4qxzrNKG8zA@mail.gmail.com","threadId":"39226","inReplyTo":"CAKB+oNsPzoBRUn6rD3Bb8soHEub3quT76MB25KyWfcEC1smdJg@mail.gmail.com","subject":"Re: [Patch] Added http-protocol for git in the Documentation folder","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-05-03T17:12:21Z","receivedAt":"2015-05-03T17:12:21Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, May 3, 2015 at 12:18 PM, Alangi Derick wrote:\n> This patch is to include the http-protocol in the documentations\n> folder as stated by the left over projects here:\n> http://git-blame.blogspot.de/p/leftover-bits.html.\n> I got the documentation uploaded by Scott in his drop box some years ago.\n> https://www.dropbox.com/s/pwawp8kmwgyc3w2/http-protocol.txt\n\nThis document was imported into the project by 4c6fffe (Document the\nHTTP transport protocols, 2013-08-21) at\nDocumentation/technical/http-protocol.txt and has already seen several\nchanges since then.\n"},{"id":"260471","messageId":"CAPig+cTVMhSwQ_z15GLCn6AmAsm6Pv0RJuGxpVg2CnX8whp8Yw@mail.gmail.com","threadId":"39226","inReplyTo":"CAPig+cSJWdrS-bBXcHE5ZmpZ3Aj8tKehXgFan6=4qxzrNKG8zA@mail.gmail.com","subject":"Re: [Patch] Added http-protocol for git in the Documentation folder","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-05-03T17:15:31Z","receivedAt":"2015-05-03T17:15:31Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, May 3, 2015 at 1:12 PM, Eric Sunshine wrote:\n> On Sun, May 3, 2015 at 12:18 PM, Alangi Derick wrote:\n>> This patch is to include the http-protocol in the documentations\n>> folder as stated by the left over projects here:\n>> http://git-blame.blogspot.de/p/leftover-bits.html.\n>> I got the documentation uploaded by Scott in his drop box some years ago.\n>> https://www.dropbox.com/s/pwawp8kmwgyc3w2/http-protocol.txt\n>\n> This document was imported into the project by 4c6fffe (Document the\n> HTTP transport protocols, 2013-08-21) at\n> Documentation/technical/http-protocol.txt and has already seen several\n> changes since then.\n\nBy the way, the entry in Junio's \"Leftover Bits\" isn't about importing\nhttp-protocol.txt, but rather about fleshing out all the TODO items\nwhich are still present in the document.\n"},{"id":"260478","messageId":"xmqqlhh5v923.fsf@gitster.dls.corp.google.com","threadId":"39226","inReplyTo":"CAPig+cTVMhSwQ_z15GLCn6AmAsm6Pv0RJuGxpVg2CnX8whp8Yw@mail.gmail.com","subject":"Re: [Patch] Added http-protocol for git in the Documentation folder","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-03T17:56:52Z","receivedAt":"2015-05-03T17:56:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> By the way, the entry in Junio's \"Leftover Bits\" isn't about importing\n> http-protocol.txt, but rather about fleshing out all the TODO items\n> which are still present in the document.\n\nThanks for saving my time ;-)\n"}]}