doc: apply synopsis simplification on git-clone and git-init
With the new synopsis formatting backend, no special asciidoc markup is needed. 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
Sep 24, 2024 at 07:08 UTC
22293895c000e89997b2197a7b2b17cdf3a36369
3 files changed
+67
-72
Documentation/git-clone.txt
+39
-39
@@ -8,16 +8,16 @@ git-clone - Clone a repository into a new directory
8
9
SYNOPSIS
10
--------
11
-[verse]
12
-`git clone` [++--template=++__<template-directory>__]
13
- [`-l`] [`-s`] [`--no-hardlinks`] [`-q`] [`-n`] [`--bare`] [`--mirror`]
14
- [`-o` _<name>_] [`-b` _<name>_] [`-u` _<upload-pack>_] [`--reference` _<repository>_]
15
- [`--dissociate`] [`--separate-git-dir` _<git-dir>_]
16
- [`--depth` _<depth>_] [`--`[`no-`]{empty}`single-branch`] [`--no-tags`]
17
- [++--recurse-submodules++[++=++__<pathspec>__]] [++--++[++no-++]{empty}++shallow-submodules++]
18
- [`--`[`no-`]{empty}`remote-submodules`] [`--jobs` _<n>_] [`--sparse`] [`--`[`no-`]{empty}`reject-shallow`]
19
- [++--filter=++__<filter-spec>__] [`--also-filter-submodules`]] [`--`] _<repository>_
20
- [_<directory>_]
11
+[synopsis]
12
+git clone [--template=<template-directory>]
13
+ [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
14
+ [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
15
+ [--dissociate] [--separate-git-dir <git-dir>]
16
+ [--depth <depth>] [--[no-]single-branch] [--no-tags]
17
+ [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
18
+ [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow]
19
+ [--filter=<filter-spec>] [--also-filter-submodules]] [--] <repository>
20
+ [<directory>]
21
22
DESCRIPTION
23
-----------
@@ -52,7 +52,7 @@ OPTIONS
52
to save space when possible.
53
+
54
If the repository is specified as a local path (e.g., `/path/to/repo`),
55
-this is the default, and --local is essentially a no-op. If the
55
+this is the default, and `--local` is essentially a no-op. If the
56
repository is specified as a URL, then this flag is ignored (and we
57
never use the local optimizations). Specifying `--no-local` will
58
override the default when `/path/to/repo` is given, using the regular
@@ -64,8 +64,8 @@ prevent the unintentional copying of files by dereferencing the symbolic
64
links.
65
+
66
*NOTE*: this operation can race with concurrent modification to the
67
-source repository, similar to running `cp -r src dst` while modifying
68
-`src`.
67
+source repository, similar to running `cp -r <src> <dst>` while modifying
68
+_<src>_.
69
70
`--no-hardlinks`::
71
Force the cloning process from a repository on a local
@@ -101,7 +101,7 @@ If you want to break the dependency of a repository cloned with `--shared` on
101
its source repository, you can simply run `git repack -a` to copy all
102
objects from the source repository into a pack in the cloned repository.
103
104
-`--reference`[`-if-able`] _<repository>_::
104
+`--reference[-if-able] <repository>`::
105
If the reference _<repository>_ is on the local machine,
106
automatically setup `.git/objects/info/alternates` to
107
obtain objects from the reference _<repository>_. Using
@@ -142,17 +142,17 @@ objects from the source repository into a pack in the cloned repository.
142
is specified. This flag forces progress status even if the
143
standard error stream is not directed to a terminal.
144
145
-++--server-option=++__<option>__::
145
+`--server-option=<option>`::
146
Transmit the given string to the server when communicating using
147
protocol version 2. The given string must not contain a NUL or LF
148
character. The server's handling of server options, including
149
unknown ones, is server-specific.
150
- When multiple ++--server-option=++__<option>__ are given, they are all
150
+ When multiple `--server-option=<option>` are given, they are all
151
sent to the other side in the order listed on the command line.
152
153
`-n`::
154
`--no-checkout`::
155
- No checkout of HEAD is performed after the clone is complete.
155
+ No checkout of `HEAD` is performed after the clone is complete.
156
157
`--`[`no-`]`reject-shallow`::
158
Fail if the source repository is a shallow repository.
@@ -162,7 +162,7 @@ objects from the source repository into a pack in the cloned repository.
162
`--bare`::
163
Make a 'bare' Git repository. That is, instead of
164
creating _<directory>_ and placing the administrative
165
- files in _<directory>_`/.git`, make the _<directory>_
165
+ files in `<directory>/.git`, make the _<directory>_
166
itself the `$GIT_DIR`. This obviously implies the `--no-checkout`
167
because there is nowhere to check out the working tree.
168
Also the branch heads at the remote are copied directly
@@ -177,13 +177,13 @@ objects from the source repository into a pack in the cloned repository.
177
linkgit:git-sparse-checkout[1] command can be used to grow the
178
working directory as needed.
179
180
-++--filter=++__<filter-spec>__::
180
+`--filter=<filter-spec>`::
181
Use the partial clone feature and request that the server sends
182
a subset of reachable objects according to a given object filter.
183
When using `--filter`, the supplied _<filter-spec>_ is used for
184
the partial clone filter. For example, `--filter=blob:none` will
185
filter out all blobs (file contents) until needed by Git. Also,
186
- ++--filter=blob:limit=++__<size>__ will filter out all blobs of size
186
+ `--filter=blob:limit=<size>` will filter out all blobs of size
187
at least _<size>_. For more details on filter specifications, see
188
the `--filter` option in linkgit:git-rev-list[1].
189
@@ -208,11 +208,11 @@ objects from the source repository into a pack in the cloned repository.
208
209
`-b` _<name>_::
210
`--branch` _<name>_::
211
- Instead of pointing the newly created HEAD to the branch pointed
212
- to by the cloned repository's HEAD, point to _<name>_ branch
211
+ Instead of pointing the newly created `HEAD` to the branch pointed
212
+ to by the cloned repository's `HEAD`, point to _<name>_ branch
213
instead. In a non-bare repository, this is the branch that will
214
be checked out.
215
- `--branch` can also take tags and detaches the HEAD at that commit
215
+ `--branch` can also take tags and detaches the `HEAD` at that commit
216
in the resulting repository.
217
218
`-u` _<upload-pack>_::
@@ -221,12 +221,12 @@ objects from the source repository into a pack in the cloned repository.
221
via ssh, this specifies a non-default path for the command
222
run on the other end.
223
224
-++--template=++__<template-directory>__::
224
+`--template=<template-directory>`::
225
Specify the directory from which templates will be used;
226
(See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
227
228
-`-c` __<key>__++=++__<value>__::
229
-`--config` __<key>__++=++__<value>__::
228
+`-c` `<key>=<value>`::
229
+`--config` `<key>=<value>`::
230
Set a configuration variable in the newly-created repository;
231
this takes effect immediately after the repository is
232
initialized, but before the remote history is fetched or any
@@ -239,25 +239,25 @@ objects from the source repository into a pack in the cloned repository.
239
Due to limitations of the current implementation, some configuration
240
variables do not take effect until after the initial fetch and checkout.
241
Configuration variables known to not take effect are:
242
-++remote.++__<name>__++.mirror++ and ++remote.++__<name>__++.tagOpt++. Use the
242
+`remote.<name>.mirror` and `remote.<name>.tagOpt`. Use the
243
corresponding `--mirror` and `--no-tags` options instead.
244
245
-`--depth` _<depth>_::
245
+`--depth <depth>`::
246
Create a 'shallow' clone with a history truncated to the
247
specified number of commits. Implies `--single-branch` unless
248
`--no-single-branch` is given to fetch the histories near the
249
tips of all branches. If you want to clone submodules shallowly,
250
also pass `--shallow-submodules`.
251
252
-++--shallow-since=++__<date>__::
252
+`--shallow-since=<date>`::
253
Create a shallow clone with a history after the specified time.
254
255
-++--shallow-exclude=++__<revision>__::
255
+`--shallow-exclude=<revision>`::
256
Create a shallow clone with a history, excluding commits
257
reachable from a specified remote branch or tag. This option
258
can be specified multiple times.
259
260
-`--`[`no-`]`single-branch`::
260
+`--[no-]single-branch`::
261
Clone only the history leading to the tip of a single branch,
262
either specified by the `--branch` option or the primary
263
branch remote's `HEAD` points at.
@@ -279,13 +279,13 @@ maintain a branch with no references other than a single cloned
279
branch. This is useful e.g. to maintain minimal clones of the default
280
branch of some repository for search indexing.
281
282
-`--recurse-submodules`[`=`{empty}__<pathspec>__]::
282
+`--recurse-submodules[=<pathspec>]`::
283
After the clone is created, initialize and clone submodules
284
- within based on the provided _<pathspec>_. If no _=<pathspec>_ is
284
+ within based on the provided _<pathspec>_. If no `=<pathspec>` is
285
provided, all submodules are initialized and cloned.
286
This option can be given multiple times for pathspecs consisting
287
of multiple entries. The resulting clone has `submodule.active` set to
288
- the provided pathspec, or "." (meaning all submodules) if no
288
+ the provided pathspec, or "`.`" (meaning all submodules) if no
289
pathspec is provided.
290
+
291
Submodules are initialized and cloned using their default settings. This is
@@ -295,23 +295,23 @@ the clone is finished. This option is ignored if the cloned repository does
295
not have a worktree/checkout (i.e. if any of `--no-checkout`/`-n`, `--bare`,
296
or `--mirror` is given)
297
298
-`--`[`no-`]`shallow-submodules`::
298
+`--[no-]shallow-submodules`::
299
All submodules which are cloned will be shallow with a depth of 1.
300
301
-`--`[`no-`]`remote-submodules`::
301
+`--[no-]remote-submodules`::
302
All submodules which are cloned will use the status of the submodule's
303
remote-tracking branch to update the submodule, rather than the
304
superproject's recorded SHA-1. Equivalent to passing `--remote` to
305
`git submodule update`.
306
307
-`--separate-git-dir=`{empty}__<git-dir>__::
307
+`--separate-git-dir=<git-dir>`::
308
Instead of placing the cloned repository where it is supposed
309
to be, place the cloned repository at the specified directory,
310
then make a filesystem-agnostic Git symbolic link to there.
311
The result is Git repository can be separated from working
312
tree.
313
314
-`--ref-format=`{empty}__<ref-format>__::
314
+`--ref-format=<ref-format>`::
315
316
Specify the given ref storage format for the repository. The valid values are:
317
+
@@ -334,7 +334,7 @@ _<directory>_::
334
for `host.xz:foo/.git`). Cloning into an existing directory
335
is only allowed if the directory is empty.
336
337
-`--bundle-uri=`{empty}__<uri>__::
337
+`--bundle-uri=<uri>`::
338
Before fetching from the remote, fetch a bundle from the given
339
_<uri>_ and unbundle the data into the local repository. The refs
340
in the bundle will be stored under the hidden `refs/bundle/*`
Documentation/git-init.txt
+15
-20
@@ -8,12 +8,12 @@ git-init - Create an empty Git repository or reinitialize an existing one
8
9
SYNOPSIS
10
--------
11
-[verse]
12
-`git init` [`-q` | `--quiet`] [`--bare`] [++--template=++__<template-directory>__]
13
- [`--separate-git-dir` _<git-dir>_] [++--object-format=++__<format>__]
14
- [++--ref-format=++__<format>__]
15
- [`-b` _<branch-name>_ | ++--initial-branch=++__<branch-name>__]
16
- [++--shared++[++=++__<permissions>__]] [_<directory>_]
11
+[synopsis]
12
+git init [-q | --quiet] [--bare] [--template=<template-directory>]
13
+ [--separate-git-dir <git-dir>] [--object-format=<format>]
14
+ [--ref-format=<format>]
15
+ [-b <branch-name> | --initial-branch=<branch-name>]
16
+ [--shared[=<permissions>]] [<directory>]
17
18
19
DESCRIPTION
@@ -25,11 +25,11 @@ directory with subdirectories for `objects`, `refs/heads`,
25
commits will be created (see the `--initial-branch` option below
26
for its name).
27
28
-If the `$GIT_DIR` environment variable is set then it specifies a path
28
+If the `GIT_DIR` environment variable is set then it specifies a path
29
to use instead of `./.git` for the base of the repository.
30
31
If the object storage directory is specified via the
32
-`$GIT_OBJECT_DIRECTORY` environment variable then the sha1 directories
32
+`GIT_OBJECT_DIRECTORY` environment variable then the sha1 directories
33
are created underneath; otherwise, the default `$GIT_DIR/objects`
34
directory is used.
35
@@ -51,26 +51,22 @@ Only print error and warning messages; all other output will be suppressed.
51
Create a bare repository. If `GIT_DIR` environment is not set, it is set to the
52
current working directory.
53
54
-++--object-format=++__<format>__::
55
-
54
+`--object-format=<format>`::
55
Specify the given object _<format>_ (hash algorithm) for the repository. The valid
56
values are `sha1` and (if enabled) `sha256`. `sha1` is the default.
57
+
58
include::object-format-disclaimer.txt[]
59
61
-++--ref-format=++__<format>__::
62
-
60
+`--ref-format=<format>`::
61
Specify the given ref storage _<format>_ for the repository. The valid values are:
62
+
63
include::ref-storage-format.txt[]
64
67
-++--template=++__<template-directory>__::
68
-
65
+`--template=<template-directory>`::
66
Specify the directory from which templates will be used. (See the "TEMPLATE
67
DIRECTORY" section below.)
68
72
-++--separate-git-dir=++__<git-dir>__::
73
-
69
+`--separate-git-dir=<git-dir>`::
70
Instead of initializing the repository as a directory to either `$GIT_DIR` or
71
`./.git/`, create a text file there containing the path to the actual
72
repository. This file acts as a filesystem-agnostic Git symbolic link to the
@@ -78,15 +74,14 @@ repository.
74
+
75
If this is a reinitialization, the repository will be moved to the specified path.
76
81
-`-b` _<branch-name>_::
82
-++--initial-branch=++__<branch-name>__::
83
-
77
+`-b <branch-name>`::
78
+`--initial-branch=<branch-name>`::
79
Use _<branch-name>_ for the initial branch in the newly created
80
repository. If not specified, fall back to the default name (currently
81
`master`, but this is subject to change in the future; the name can be
82
customized via the `init.defaultBranch` configuration variable).
83
89
-++--shared++[++=++(`false`|`true`|`umask`|`group`|`all`|`world`|`everybody`|_<perm>_)]::
84
+`--shared[=(false|true|umask|group|all|world|everybody|<perm>)]`::
85
86
Specify that the Git repository is to be shared amongst several users. This
87
allows users belonging to the same group to push into that
Documentation/urls.txt
+13
-13
@@ -10,19 +10,19 @@ Git supports ssh, git, http, and https protocols (in addition, ftp
10
and ftps can be used for fetching, but this is inefficient and
11
deprecated; do not use them).
12
13
-The native transport (i.e. git:// URL) does no authentication and
13
+The native transport (i.e. `git://` URL) does no authentication and
14
should be used with caution on unsecured networks.
15
16
The following syntaxes may be used with them:
17
18
-- ++ssh://++{startsb}__<user>__++@++{endsb}__<host>__{startsb}++:++__<port>__{endsb}++/++__<path-to-git-repo>__
19
-- ++git://++__<host>__{startsb}:__<port>__{endsb}++/++__<path-to-git-repo>__
20
-- ++http++{startsb}++s++{endsb}++://++__<host>__{startsb}++:++__<port>__{endsb}++/++__<path-to-git-repo>__
21
-- ++ftp++{startsb}++s++{endsb}++://++__<host>__{startsb}++:++__<port>__{endsb}++/++__<path-to-git-repo>__
18
+- `ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>`
19
+- `git://<host>[:<port>]/<path-to-git-repo>`
20
+- `http[s]://<host>[:<port>]/<path-to-git-repo>`
21
+- `ftp[s]://<host>[:<port>]/<path-to-git-repo>`
22
23
An alternative scp-like syntax may also be used with the ssh protocol:
24
25
-- {startsb}__<user>__++@++{endsb}__<host>__++:/++__<path-to-git-repo>__
25
+- `[<user>@]<host>:/<path-to-git-repo>`
26
27
This syntax is only recognized if there are no slashes before the
28
first colon. This helps differentiate a local path that contains a
@@ -30,17 +30,17 @@ colon. For example the local path `foo:bar` could be specified as an
30
absolute path or `./foo:bar` to avoid being misinterpreted as an ssh
31
url.
32
33
-The ssh and git protocols additionally support ++~++__<username>__ expansion:
33
+The ssh and git protocols additionally support `~<username>` expansion:
34
35
-- ++ssh://++{startsb}__<user>__++@++{endsb}__<host>__{startsb}++:++__<port>__{endsb}++/~++__<user>__++/++__<path-to-git-repo>__
36
-- ++git://++__<host>__{startsb}++:++__<port>__{endsb}++/~++__<user>__++/++__<path-to-git-repo>__
37
-- {startsb}__<user>__++@++{endsb}__<host>__++:~++__<user>__++/++__<path-to-git-repo>__
35
+- `ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>`
36
+- `git://<host>[:<port>]/~<user>/<path-to-git-repo>`
37
+- `[<user>@]<host>:~<user>/<path-to-git-repo>`
38
39
For local repositories, also supported by Git natively, the following
40
syntaxes may be used:
41
42
- `/path/to/repo.git/`
43
-- ++file:///path/to/repo.git/++
43
+- `file:///path/to/repo.git/`
44
45
ifndef::git-clone[]
46
These two syntaxes are mostly equivalent, except when cloning, when
@@ -57,11 +57,11 @@ endif::git-clone[]
57
accept a suitable bundle file. See linkgit:git-bundle[1].
58
59
When Git doesn't know how to handle a certain transport protocol, it
60
-attempts to use the `remote-`{empty}__<transport>__ remote helper, if one
60
+attempts to use the `remote-<transport>` remote helper, if one
61
exists. To explicitly request a remote helper, the following syntax
62
may be used:
63
64
-- _<transport>_::__<address>__
64
+- `<transport>::<address>`
65
66
where _<address>_ may be a path, a server and path, or an arbitrary
67
URL-like string recognized by the specific remote helper being