Documentation/technical: convert plain text files to asciidoc
These were not originally meant for asciidoc, but they are already so close. Mark them up in asciidoc. Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Ackermann committed
Oct 16, 2012 at 19:24 UTC
5316c8e9399dacd9e0f7c22132f3ad67186408ed
5 files changed
+34
-27
Documentation/technical/index-format.txt
+1
-1
@@ -1,7 +1,7 @@
1
GIT index format
2
================
3
4
-= The git index file has the following format
4
+== The git index file has the following format
5
6
All binary numbers are in network byte order. Version 2 is described
7
here unless stated otherwise.
Documentation/technical/pack-format.txt
+4
-4
@@ -1,7 +1,7 @@
1
GIT pack format
2
===============
3
4
-= pack-*.pack files have the following format:
4
+== pack-*.pack files have the following format:
5
6
- A header appears at the beginning and consists of the following:
7
@@ -34,7 +34,7 @@ GIT pack format
34
35
- The trailer records 20-byte SHA1 checksum of all of the above.
36
37
-= Original (version 1) pack-*.idx files have the following format:
37
+== Original (version 1) pack-*.idx files have the following format:
38
39
- The header consists of 256 4-byte network byte order
40
integers. N-th entry of this table records the number of
@@ -123,8 +123,8 @@ Pack file entry: <+
123
124
125
126
-= Version 2 pack-*.idx files support packs larger than 4 GiB, and
127
- have some other reorganizations. They have the format:
126
+== Version 2 pack-*.idx files support packs larger than 4 GiB, and
127
+ have some other reorganizations. They have the format:
128
129
- A 4-byte magic number '\377tOc' which is an unreasonable
130
fanout[0] value.
Documentation/technical/pack-protocol.txt
+4
-3
@@ -117,7 +117,7 @@ A few things to remember here:
117
- The repository path is always quoted with single quotes.
118
119
Fetching Data From a Server
120
-===========================
120
+---------------------------
121
122
When one Git repository wants to get data that a second repository
123
has, the first can 'fetch' from the second. This operation determines
@@ -134,7 +134,8 @@ with the object name that each reference currently points to.
134
135
$ echo -e -n "0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" |
136
nc -v example.com 9418
137
- 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag
137
+ 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack
138
+ side-band side-band-64k ofs-delta shallow no-progress include-tag
139
00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration
140
003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master
141
003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9
@@ -421,7 +422,7 @@ entire packfile without multiplexing.
422
423
424
Pushing Data To a Server
424
-========================
425
+------------------------
426
427
Pushing data to a server will invoke the 'receive-pack' process on the
428
server, which will allow the client to tell it which references it should
Documentation/technical/shallow.txt
+7
-1
@@ -1,6 +1,12 @@
1
-Def.: Shallow commits do have parents, but not in the shallow
1
+Shallow commits
2
+===============
3
+
4
+.Definition
5
+*********************************************************
6
+Shallow commits do have parents, but not in the shallow
7
repo, and therefore grafts are introduced pretending that
8
these commits have no parents.
9
+*********************************************************
10
11
The basic idea is to write the SHA1s of shallow commits into
12
$GIT_DIR/shallow, and handle its contents like the contents
Documentation/technical/trivial-merge.txt
+18
-18
@@ -74,24 +74,24 @@ For multiple ancestors, a '+' means that this case applies even if
74
only one ancestor or remote fits; a '^' means all of the ancestors
75
must be the same.
76
77
-case ancest head remote result
78
-----------------------------------------
79
-1 (empty)+ (empty) (empty) (empty)
80
-2ALT (empty)+ *empty* remote remote
81
-2 (empty)^ (empty) remote no merge
82
-3ALT (empty)+ head *empty* head
83
-3 (empty)^ head (empty) no merge
84
-4 (empty)^ head remote no merge
85
-5ALT * head head head
86
-6 ancest+ (empty) (empty) no merge
87
-8 ancest^ (empty) ancest no merge
88
-7 ancest+ (empty) remote no merge
89
-10 ancest^ ancest (empty) no merge
90
-9 ancest+ head (empty) no merge
91
-16 anc1/anc2 anc1 anc2 no merge
92
-13 ancest+ head ancest head
93
-14 ancest+ ancest remote remote
94
-11 ancest+ head remote no merge
77
+ case ancest head remote result
78
+ ----------------------------------------
79
+ 1 (empty)+ (empty) (empty) (empty)
80
+ 2ALT (empty)+ *empty* remote remote
81
+ 2 (empty)^ (empty) remote no merge
82
+ 3ALT (empty)+ head *empty* head
83
+ 3 (empty)^ head (empty) no merge
84
+ 4 (empty)^ head remote no merge
85
+ 5ALT * head head head
86
+ 6 ancest+ (empty) (empty) no merge
87
+ 8 ancest^ (empty) ancest no merge
88
+ 7 ancest+ (empty) remote no merge
89
+ 10 ancest^ ancest (empty) no merge
90
+ 9 ancest+ head (empty) no merge
91
+ 16 anc1/anc2 anc1 anc2 no merge
92
+ 13 ancest+ head ancest head
93
+ 14 ancest+ ancest remote remote
94
+ 11 ancest+ head remote no merge
95
96
Only #2ALT and #3ALT use *empty*, because these are the only cases
97
where there can be conflicts that didn't exist before. Note that we