freshlybakedca.ke
Git fork
Merge branch 'kh/doc-continued-paragraph-fix'
Doc mark-up fixes.
* kh/doc-continued-paragraph-fix:
doc: fix accidental literal blocks
+2
-2
Documentation/config/core.adoc
+2
-2
Documentation/config/core.adoc
···
75
75
limited set of supported platforms. Currently, this includes Windows
76
76
and MacOS.
77
77
+
78
-
Otherwise, this variable contains the pathname of the "fsmonitor"
79
-
hook command.
78
+
Otherwise, this variable contains the pathname of the "fsmonitor"
79
+
hook command.
80
80
+
81
81
This hook command is used to identify all files that may have changed
82
82
since the requested date/time. This information is used to speed up
+9
-9
Documentation/git-config.adoc
+9
-9
Documentation/git-config.adoc
···
117
117
118
118
--comment <message>::
119
119
Append a comment at the end of new or modified lines.
120
-
121
-
If _<message>_ begins with one or more whitespaces followed
122
-
by "#", it is used as-is. If it begins with "#", a space is
123
-
prepended before it is used. Otherwise, a string " # " (a
124
-
space followed by a hash followed by a space) is prepended
125
-
to it. And the resulting string is placed immediately after
126
-
the value defined for the variable. The _<message>_ must
127
-
not contain linefeed characters (no multi-line comments are
128
-
permitted).
120
+
+
121
+
If _<message>_ begins with one or more whitespaces followed
122
+
by "#", it is used as-is. If it begins with "#", a space is
123
+
prepended before it is used. Otherwise, a string " # " (a
124
+
space followed by a hash followed by a space) is prepended
125
+
to it. And the resulting string is placed immediately after
126
+
the value defined for the variable. The _<message>_ must
127
+
not contain linefeed characters (no multi-line comments are
128
+
permitted).
129
129
130
130
--all::
131
131
With `get`, return all values for a multi-valued key.
+7
-7
Documentation/git-rev-parse.adoc
+7
-7
Documentation/git-rev-parse.adoc
···
174
174
175
175
Allow oids to be input from any object format that the current
176
176
repository supports.
177
-
178
-
Specifying "sha1" translates if necessary and returns a sha1 oid.
179
-
180
-
Specifying "sha256" translates if necessary and returns a sha256 oid.
181
-
182
-
Specifying "storage" translates if necessary and returns an oid in
183
-
encoded in the storage hash algorithm.
177
+
+
178
+
Specifying "sha1" translates if necessary and returns a sha1 oid.
179
+
+
180
+
Specifying "sha256" translates if necessary and returns a sha256 oid.
181
+
+
182
+
Specifying "storage" translates if necessary and returns an oid in
183
+
encoded in the storage hash algorithm.
184
184
185
185
Options for Objects
186
186
~~~~~~~~~~~~~~~~~~~
+2
-2
Documentation/git-shortlog.adoc
+2
-2
Documentation/git-shortlog.adoc
···
44
44
describe each commit. '<format>' can be any string accepted
45
45
by the `--format` option of 'git log', such as '* [%h] %s'.
46
46
(See the "PRETTY FORMATS" section of linkgit:git-log[1].)
47
-
48
-
Each pretty-printed commit will be rewrapped before it is shown.
47
+
+
48
+
Each pretty-printed commit will be rewrapped before it is shown.
49
49
50
50
--date=<format>::
51
51
Show dates formatted according to the given date string. (See
+44
-28
Documentation/git-sparse-checkout.adoc
+44
-28
Documentation/git-sparse-checkout.adoc
···
264
264
inconsistent.
265
265
266
266
* It has edge cases where the "right" behavior is unclear. Two examples:
267
-
268
-
First, two users are in a subdirectory, and the first runs
269
-
git sparse-checkout set '/toplevel-dir/*.c'
270
-
while the second runs
271
-
git sparse-checkout set relative-dir
272
-
Should those arguments be transliterated into
273
-
current/subdirectory/toplevel-dir/*.c
274
-
and
275
-
current/subdirectory/relative-dir
276
-
before inserting into the sparse-checkout file? The user who typed
277
-
the first command is probably aware that arguments to set/add are
278
-
supposed to be patterns in non-cone mode, and probably would not be
279
-
happy with such a transliteration. However, many gitignore-style
280
-
patterns are just paths, which might be what the user who typed the
281
-
second command was thinking, and they'd be upset if their argument
282
-
wasn't transliterated.
283
-
284
-
Second, what should bash-completion complete on for set/add commands
285
-
for non-cone users? If it suggests paths, is it exacerbating the
286
-
problem above? Also, if it suggests paths, what if the user has a
287
-
file or directory that begins with either a '!' or '#' or has a '*',
288
-
'\', '?', '[', or ']' in its name? And if it suggests paths, will
289
-
it complete "/pro" to "/proc" (in the root filesystem) rather than to
290
-
"/progress.txt" in the current directory? (Note that users are
291
-
likely to want to start paths with a leading '/' in non-cone mode,
292
-
for the same reason that .gitignore files often have one.)
293
-
Completing on files or directories might give nasty surprises in
294
-
all these cases.
267
+
+
268
+
First, two users are in a subdirectory, and the first runs
269
+
+
270
+
----
271
+
git sparse-checkout set '/toplevel-dir/*.c'
272
+
----
273
+
+
274
+
while the second runs
275
+
+
276
+
----
277
+
git sparse-checkout set relative-dir
278
+
----
279
+
+
280
+
Should those arguments be transliterated into
281
+
+
282
+
----
283
+
current/subdirectory/toplevel-dir/*.c
284
+
----
285
+
+
286
+
and
287
+
+
288
+
----
289
+
current/subdirectory/relative-dir
290
+
----
291
+
+
292
+
before inserting into the sparse-checkout file? The user who typed
293
+
the first command is probably aware that arguments to set/add are
294
+
supposed to be patterns in non-cone mode, and probably would not be
295
+
happy with such a transliteration. However, many gitignore-style
296
+
patterns are just paths, which might be what the user who typed the
297
+
second command was thinking, and they'd be upset if their argument
298
+
wasn't transliterated.
299
+
+
300
+
Second, what should bash-completion complete on for set/add commands
301
+
for non-cone users? If it suggests paths, is it exacerbating the
302
+
problem above? Also, if it suggests paths, what if the user has a
303
+
file or directory that begins with either a '!' or '#' or has a '*',
304
+
'\', '?', '[', or ']' in its name? And if it suggests paths, will
305
+
it complete "/pro" to "/proc" (in the root filesystem) rather than to
306
+
"/progress.txt" in the current directory? (Note that users are
307
+
likely to want to start paths with a leading '/' in non-cone mode,
308
+
for the same reason that .gitignore files often have one.)
309
+
Completing on files or directories might give nasty surprises in
310
+
all these cases.
295
311
296
312
* The excessive flexibility made other extensions essentially
297
313
impractical. `--sparse-index` is likely impossible in non-cone