doc: tidy asciidoc style
This mainly refers to enforcing indentation on additional lines of items of lists. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jean-Noël Avila committed
Jan 22, 2019 at 21:16 UTC
ba170517be039a04b1914ebe9b492d4139c707df
14 files changed
+93
-94
Documentation/git-add.txt
+4
-4
@@ -58,9 +58,9 @@ OPTIONS
58
specifying `dir` will record not just a file `dir/file1`
59
modified in the working tree, a file `dir/file2` added to
60
the working tree, but also a file `dir/file3` removed from
61
- the working tree. Note that older versions of Git used
61
+ the working tree). Note that older versions of Git used
62
to ignore removed files; use `--no-all` option if you want
63
- to add modified or new files but ignore removed ones.
63
+ to add modified or new files but ignore removed ones.
64
+
65
For more details about the <pathspec> syntax, see the 'pathspec' entry
66
in linkgit:gitglossary[7].
@@ -124,7 +124,7 @@ subdirectories).
124
--no-ignore-removal::
125
Update the index not only where the working tree has a file
126
matching <pathspec> but also where the index already has an
127
- entry. This adds, modifies, and removes index entries to
127
+ entry. This adds, modifies, and removes index entries to
128
match the working tree.
129
+
130
If no <pathspec> is given when `-A` option is used, all
@@ -206,7 +206,7 @@ EXAMPLES
206
--------
207
208
* Adds content from all `*.txt` files under `Documentation` directory
209
-and its subdirectories:
209
+ and its subdirectories:
210
+
211
------------
212
$ git add Documentation/\*.txt
Documentation/git-branch.txt
+4
-4
@@ -297,7 +297,7 @@ $ git checkout my2.6.14
297
------------
298
+
299
<1> This step and the next one could be combined into a single step with
300
-"checkout -b my2.6.14 v2.6.14".
300
+ "checkout -b my2.6.14 v2.6.14".
301
302
Delete an unneeded branch::
303
+
@@ -309,10 +309,10 @@ $ git branch -D test <2>
309
------------
310
+
311
<1> Delete the remote-tracking branches "todo", "html" and "man". The next
312
-'fetch' or 'pull' will create them again unless you configure them not to.
313
-See linkgit:git-fetch[1].
312
+ 'fetch' or 'pull' will create them again unless you configure them not to.
313
+ See linkgit:git-fetch[1].
314
<2> Delete the "test" branch even if the "master" branch (or whichever branch
315
-is currently checked out) does not have all commits from the test branch.
315
+ is currently checked out) does not have all commits from the test branch.
316
317
318
NOTES
Documentation/git-checkout.txt
+8
-8
@@ -420,14 +420,14 @@ $ git tag foo <3>
420
------------
421
422
<1> creates a new branch 'foo', which refers to commit 'f', and then
423
-updates HEAD to refer to branch 'foo'. In other words, we'll no longer
424
-be in detached HEAD state after this command.
423
+ updates HEAD to refer to branch 'foo'. In other words, we'll no longer
424
+ be in detached HEAD state after this command.
425
426
<2> similarly creates a new branch 'foo', which refers to commit 'f',
427
-but leaves HEAD detached.
427
+ but leaves HEAD detached.
428
429
<3> creates a new tag 'foo', which refers to commit 'f',
430
-leaving HEAD detached.
430
+ leaving HEAD detached.
431
432
If we have moved away from commit 'f', then we must first recover its object
433
name (typically by using git reflog), and then we can create a reference to
@@ -455,8 +455,8 @@ EXAMPLES
455
--------
456
457
. The following sequence checks out the `master` branch, reverts
458
-the `Makefile` to two revisions back, deletes hello.c by
459
-mistake, and gets it back from the index.
458
+ the `Makefile` to two revisions back, deletes hello.c by
459
+ mistake, and gets it back from the index.
460
+
461
------------
462
$ git checkout master <1>
@@ -490,7 +490,7 @@ $ git checkout -- hello.c
490
------------
491
492
. After working in the wrong branch, switching to the correct
493
-branch would be done using:
493
+ branch would be done using:
494
+
495
------------
496
$ git checkout mytopic
@@ -518,7 +518,7 @@ registered in your index file, so `git diff` would show you what
518
changes you made since the tip of the new branch.
519
520
. When a merge conflict happens during switching branches with
521
-the `-m` option, you would see something like this:
521
+ the `-m` option, you would see something like this:
522
+
523
------------
524
$ git checkout -m mytopic
Documentation/git-cherry-pick.txt
+7
-7
@@ -213,16 +213,16 @@ $ git reset --merge ORIG_HEAD <3>
213
$ git cherry-pick -Xpatience topic^ <4>
214
------------
215
<1> apply the change that would be shown by `git show topic^`.
216
-In this example, the patch does not apply cleanly, so
217
-information about the conflict is written to the index and
218
-working tree and no new commit results.
216
+ In this example, the patch does not apply cleanly, so
217
+ information about the conflict is written to the index and
218
+ working tree and no new commit results.
219
<2> summarize changes to be reconciled
220
<3> cancel the cherry-pick. In other words, return to the
221
-pre-cherry-pick state, preserving any local modifications you had in
222
-the working tree.
221
+ pre-cherry-pick state, preserving any local modifications
222
+ you had in the working tree.
223
<4> try to apply the change introduced by `topic^` again,
224
-spending extra time to avoid mistakes based on incorrectly matching
225
-context lines.
224
+ spending extra time to avoid mistakes based on incorrectly
225
+ matching context lines.
226
227
SEE ALSO
228
--------
Documentation/git-diff.txt
+9
-9
@@ -132,9 +132,9 @@ $ git diff HEAD <3>
132
+
133
<1> Changes in the working tree not yet staged for the next commit.
134
<2> Changes between the index and your last commit; what you
135
-would be committing if you run "git commit" without "-a" option.
135
+ would be committing if you run "git commit" without "-a" option.
136
<3> Changes in the working tree since your last commit; what you
137
-would be committing if you run "git commit -a"
137
+ would be committing if you run "git commit -a"
138
139
Comparing with arbitrary commits::
140
+
@@ -145,10 +145,10 @@ $ git diff HEAD^ HEAD <3>
145
------------
146
+
147
<1> Instead of using the tip of the current branch, compare with the
148
-tip of "test" branch.
148
+ tip of "test" branch.
149
<2> Instead of comparing with the tip of "test" branch, compare with
150
-the tip of the current branch, but limit the comparison to the
151
-file "test".
150
+ the tip of the current branch, but limit the comparison to the
151
+ file "test".
152
<3> Compare the version before the last commit and the last commit.
153
154
Comparing branches::
@@ -162,7 +162,7 @@ $ git diff topic...master <3>
162
<1> Changes between the tips of the topic and the master branches.
163
<2> Same as above.
164
<3> Changes that occurred on the master branch since when the topic
165
-branch was started off it.
165
+ branch was started off it.
166
167
Limiting the diff output::
168
+
@@ -173,9 +173,9 @@ $ git diff arch/i386 include/asm-i386 <3>
173
------------
174
+
175
<1> Show only modification, rename, and copy, but not addition
176
-or deletion.
176
+ or deletion.
177
<2> Show only names and the nature of change, but not actual
178
-diff output.
178
+ diff output.
179
<3> Limit diff output to named subtrees.
180
181
Munging the diff output::
@@ -186,7 +186,7 @@ $ git diff -R <2>
186
------------
187
+
188
<1> Spend extra cycles to find renames, copies and complete
189
-rewrites (very expensive).
189
+ rewrites (very expensive).
190
<2> Output diff in reverse.
191
192
SEE ALSO
Documentation/git-fetch.txt
+1
-1
@@ -266,7 +266,7 @@ The `pu` branch will be updated even if it is does not fast-forward,
266
because it is prefixed with a plus sign; `tmp` will not be.
267
268
* Peek at a remote's branch, without configuring the remote in your local
269
-repository:
269
+ repository:
270
+
271
------------------------------------------------
272
$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
Documentation/git-format-patch.txt
+7
-7
@@ -504,9 +504,9 @@ Toggle it to make sure it is set to `false`. Also, search for
504
"mailnews.wraplength" and set the value to 0.
505
506
3. Disable the use of format=flowed:
507
-Edit..Preferences..Advanced..Config Editor. Search for
508
-"mailnews.send_plaintext_flowed".
509
-Toggle it to make sure it is set to `false`.
507
+ Edit..Preferences..Advanced..Config Editor. Search for
508
+ "mailnews.send_plaintext_flowed".
509
+ Toggle it to make sure it is set to `false`.
510
511
After that is done, you should be able to compose email as you
512
otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc),
@@ -629,14 +629,14 @@ EXAMPLES
629
--------
630
631
* Extract commits between revisions R1 and R2, and apply them on top of
632
-the current branch using 'git am' to cherry-pick them:
632
+ the current branch using 'git am' to cherry-pick them:
633
+
634
------------
635
$ git format-patch -k --stdout R1..R2 | git am -3 -k
636
------------
637
638
* Extract all commits which are in the current branch but not in the
639
-origin branch:
639
+ origin branch:
640
+
641
------------
642
$ git format-patch origin
@@ -645,7 +645,7 @@ $ git format-patch origin
645
For each commit a separate file is created in the current directory.
646
647
* Extract all commits that lead to 'origin' since the inception of the
648
-project:
648
+ project:
649
+
650
------------
651
$ git format-patch --root origin
@@ -664,7 +664,7 @@ Note that non-Git "patch" programs won't understand renaming patches, so
664
use it only when you know the recipient uses Git to apply your patch.
665
666
* Extract three topmost commits from the current branch and format them
667
-as e-mailable patches:
667
+ as e-mailable patches:
668
+
669
------------
670
$ git format-patch -3
Documentation/git-help.txt
+2
-2
@@ -118,9 +118,9 @@ format is chosen. The following values are currently supported:
118
119
* "man": use the 'man' program as usual,
120
* "woman": use 'emacsclient' to launch the "woman" mode in emacs
121
-(this only works starting with emacsclient versions 22),
121
+ (this only works starting with emacsclient versions 22),
122
* "konqueror": use 'kfmclient' to open the man page in a new konqueror
123
-tab (see 'Note about konqueror' below).
123
+ tab (see 'Note about konqueror' below).
124
125
Values for other tools can be used if there is a corresponding
126
`man.<tool>.cmd` configuration entry (see below).
Documentation/git-p4.txt
+4
-4
@@ -71,12 +71,12 @@ $ git p4 clone //depot/path/project
71
------------
72
This:
73
74
-1. Creates an empty Git repository in a subdirectory called 'project'.
74
+1. Creates an empty Git repository in a subdirectory called 'project'.
75
+
76
-2. Imports the full contents of the head revision from the given p4
77
-depot path into a single commit in the Git branch 'refs/remotes/p4/master'.
76
+2. Imports the full contents of the head revision from the given p4
77
+ depot path into a single commit in the Git branch 'refs/remotes/p4/master'.
78
+
79
-3. Creates a local branch, 'master' from this remote and checks it out.
79
+3. Creates a local branch, 'master' from this remote and checks it out.
80
81
To reproduce the entire p4 history in Git, use the '@all' modifier on
82
the depot path:
Documentation/git-reset.txt
+35
-35
@@ -115,17 +115,17 @@ $ git pull git://info.example.com/ nitfol <4>
115
------------
116
+
117
<1> You are happily working on something, and find the changes
118
-in these files are in good order. You do not want to see them
119
-when you run `git diff`, because you plan to work on other files
120
-and changes with these files are distracting.
118
+ in these files are in good order. You do not want to see them
119
+ when you run `git diff`, because you plan to work on other files
120
+ and changes with these files are distracting.
121
<2> Somebody asks you to pull, and the changes sound worthy of merging.
122
<3> However, you already dirtied the index (i.e. your index does
123
-not match the `HEAD` commit). But you know the pull you are going
124
-to make does not affect `frotz.c` or `filfre.c`, so you revert the
125
-index changes for these two files. Your changes in working tree
126
-remain there.
123
+ not match the `HEAD` commit). But you know the pull you are going
124
+ to make does not affect `frotz.c` or `filfre.c`, so you revert the
125
+ index changes for these two files. Your changes in working tree
126
+ remain there.
127
<4> Then you can pull and merge, leaving `frotz.c` and `filfre.c`
128
-changes still in the working tree.
128
+ changes still in the working tree.
129
130
Undo a commit and redo::
131
+
@@ -137,12 +137,12 @@ $ git commit -a -c ORIG_HEAD <3>
137
------------
138
+
139
<1> This is most often done when you remembered what you
140
-just committed is incomplete, or you misspelled your commit
141
-message, or both. Leaves working tree as it was before "reset".
140
+ just committed is incomplete, or you misspelled your commit
141
+ message, or both. Leaves working tree as it was before "reset".
142
<2> Make corrections to working tree files.
143
<3> "reset" copies the old head to `.git/ORIG_HEAD`; redo the
144
-commit by starting with its log message. If you do not need to
145
-edit the message further, you can give `-C` option instead.
144
+ commit by starting with its log message. If you do not need to
145
+ edit the message further, you can give `-C` option instead.
146
+
147
See also the `--amend` option to linkgit:git-commit[1].
148
@@ -155,9 +155,9 @@ $ git checkout topic/wip <3>
155
------------
156
+
157
<1> You have made some commits, but realize they were premature
158
-to be in the `master` branch. You want to continue polishing
159
-them in a topic branch, so create `topic/wip` branch off of the
160
-current `HEAD`.
158
+ to be in the `master` branch. You want to continue polishing
159
+ them in a topic branch, so create `topic/wip` branch off of the
160
+ current `HEAD`.
161
<2> Rewind the master branch to get rid of those three commits.
162
<3> Switch to `topic/wip` branch and keep working.
163
@@ -169,10 +169,10 @@ $ git reset --hard HEAD~3 <1>
169
------------
170
+
171
<1> The last three commits (`HEAD`, `HEAD^`, and `HEAD~2`) were bad
172
-and you do not want to ever see them again. Do *not* do this if
173
-you have already given these commits to somebody else. (See the
174
-"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
175
-the implications of doing so.)
172
+ and you do not want to ever see them again. Do *not* do this if
173
+ you have already given these commits to somebody else. (See the
174
+ "RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1]
175
+ for the implications of doing so.)
176
177
Undo a merge or pull::
178
+
@@ -189,18 +189,18 @@ $ git reset --hard ORIG_HEAD <4>
189
------------
190
+
191
<1> Try to update from the upstream resulted in a lot of
192
-conflicts; you were not ready to spend a lot of time merging
193
-right now, so you decide to do that later.
192
+ conflicts; you were not ready to spend a lot of time merging
193
+ right now, so you decide to do that later.
194
<2> "pull" has not made merge commit, so `git reset --hard`
195
-which is a synonym for `git reset --hard HEAD` clears the mess
196
-from the index file and the working tree.
195
+ which is a synonym for `git reset --hard HEAD` clears the mess
196
+ from the index file and the working tree.
197
<3> Merge a topic branch into the current branch, which resulted
198
-in a fast-forward.
198
+ in a fast-forward.
199
<4> But you decided that the topic branch is not ready for public
200
-consumption yet. "pull" or "merge" always leaves the original
201
-tip of the current branch in `ORIG_HEAD`, so resetting hard to it
202
-brings your index file and the working tree back to that state,
203
-and resets the tip of the branch to that commit.
200
+ consumption yet. "pull" or "merge" always leaves the original
201
+ tip of the current branch in `ORIG_HEAD`, so resetting hard to it
202
+ brings your index file and the working tree back to that state,
203
+ and resets the tip of the branch to that commit.
204
205
Undo a merge or pull inside a dirty working tree::
206
+
@@ -214,14 +214,14 @@ $ git reset --merge ORIG_HEAD <2>
214
------------
215
+
216
<1> Even if you may have local modifications in your
217
-working tree, you can safely say `git pull` when you know
218
-that the change in the other branch does not overlap with
219
-them.
217
+ working tree, you can safely say `git pull` when you know
218
+ that the change in the other branch does not overlap with
219
+ them.
220
<2> After inspecting the result of the merge, you may find
221
-that the change in the other branch is unsatisfactory. Running
222
-`git reset --hard ORIG_HEAD` will let you go back to where you
223
-were, but it will discard your local changes, which you do not
224
-want. `git reset --merge` keeps your local changes.
221
+ that the change in the other branch is unsatisfactory. Running
222
+ `git reset --hard ORIG_HEAD` will let you go back to where you
223
+ were, but it will discard your local changes, which you do not
224
+ want. `git reset --merge` keeps your local changes.
225
226
227
Interrupted workflow::
Documentation/git-send-email.txt
+1
-1
@@ -33,7 +33,7 @@ This is what linkgit:git-format-patch[1] generates. Most headers and MIME
33
formatting are ignored.
34
35
2. The original format used by Greg Kroah-Hartman's 'send_lots_of_email.pl'
36
-script
36
+ script
37
+
38
This format expects the first line of the file to contain the "Cc:" value
39
and the "Subject:" of the message as the second line.
Documentation/git-tag.txt
+8
-8
@@ -237,16 +237,16 @@ your repository directly), then others will have already seen
237
the old tag. In that case you can do one of two things:
238
239
. The sane thing.
240
-Just admit you screwed up, and use a different name. Others have
241
-already seen one tag-name, and if you keep the same name, you
242
-may be in the situation that two people both have "version X",
243
-but they actually have 'different' "X"'s. So just call it "X.1"
244
-and be done with it.
240
+ Just admit you screwed up, and use a different name. Others have
241
+ already seen one tag-name, and if you keep the same name, you
242
+ may be in the situation that two people both have "version X",
243
+ but they actually have 'different' "X"'s. So just call it "X.1"
244
+ and be done with it.
245
246
. The insane thing.
247
-You really want to call the new version "X" too, 'even though'
248
-others have already seen the old one. So just use 'git tag -f'
249
-again, as if you hadn't already published the old one.
247
+ You really want to call the new version "X" too, 'even though'
248
+ others have already seen the old one. So just use 'git tag -f'
249
+ again, as if you hadn't already published the old one.
250
251
However, Git does *not* (and it should not) change tags behind
252
users back. So if somebody already got the old tag, doing a
Documentation/git-upload-pack.txt
-1
@@ -22,7 +22,6 @@ The UI for the protocol is on the 'git fetch-pack' side, and the
22
program pair is meant to be used to pull updates from a remote
23
repository. For push operations, see 'git send-pack'.
24
25
-
25
OPTIONS
26
-------
27
Documentation/rev-list-options.txt
+3
-3
@@ -272,13 +272,13 @@ depending on a few rules:
272
+
273
--
274
1. If the starting point is specified as `ref@{Nth}`, show the index
275
-format.
275
+ format.
276
+
277
2. If the starting point was specified as `ref@{now}`, show the
278
-timestamp format.
278
+ timestamp format.
279
+
280
3. If neither was used, but `--date` was given on the command line, show
281
-the timestamp in the format requested by `--date`.
281
+ the timestamp in the format requested by `--date`.
282
+
283
4. Otherwise, show the index format.
284
--