freshlybakedca.ke
Git fork
Merge branch 'tz/doc-txt-to-adoc-fixes'
Fallouts from recent renaming of documentation files from .txt
suffix to the new .adoc suffix have been corrected.
* tz/doc-txt-to-adoc-fixes: (38 commits)
xdiff: *.txt -> *.adoc fixes
unpack-trees.c: *.txt -> *.adoc fixes
transport.h: *.txt -> *.adoc fixes
trace2/tr2_sysenv.c: *.txt -> *.adoc fixes
trace2.h: *.txt -> *.adoc fixes
t6434: *.txt -> *.adoc fixes
t6012: *.txt -> *.adoc fixes
t/helper/test-rot13-filter.c: *.txt -> *.adoc fixes
simple-ipc.h: *.txt -> *.adoc fixes
setup.c: *.txt -> *.adoc fixes
refs.h: *.txt -> *.adoc fixes
pseudo-merge.h: *.txt -> *.adoc fixes
parse-options.h: *.txt -> *.adoc fixes
object-name.c: *.txt -> *.adoc fixes
list-objects-filter-options.h: *.txt -> *.adoc fixes
fsck.h: *.txt -> *.adoc fixes
diffcore.h: *.txt -> *.adoc fixes
diff.h: *.txt -> *.adoc fixes
contrib/long-running-filter: *.txt -> *.adoc fixes
config.c: *.txt -> *.adoc fixes
...
+3
-3
.gitattributes
+3
-3
.gitattributes
···
12
/GIT-VERSION-GEN text eol=lf
13
/mergetools/* text eol=lf
14
/t/oid-info/* text eol=lf
15
-
/Documentation/git-merge.txt conflict-marker-size=32
16
-
/Documentation/gitk.txt conflict-marker-size=32
17
-
/Documentation/user-manual.txt conflict-marker-size=32
18
/t/t????-*.sh conflict-marker-size=32
···
12
/GIT-VERSION-GEN text eol=lf
13
/mergetools/* text eol=lf
14
/t/oid-info/* text eol=lf
15
+
/Documentation/git-merge.adoc conflict-marker-size=32
16
+
/Documentation/gitk.adoc conflict-marker-size=32
17
+
/Documentation/user-manual.adoc conflict-marker-size=32
18
/t/t????-*.sh conflict-marker-size=32
-1
Documentation/.gitattributes
-1
Documentation/.gitattributes
···
1
-
*.txt whitespace
···
+2
-2
Documentation/CodingGuidelines
+2
-2
Documentation/CodingGuidelines
···
44
uses (even if it doesn't match the overall style of existing code).
45
46
But if you must have a list of rules, here are some language
47
-
specific ones. Note that Documentation/ToolsForGit.txt document
48
has a collection of tips to help you use some external tools
49
to conform to these guidelines.
50
···
755
Writing Documentation:
756
757
Most (if not all) of the documentation pages are written in the
758
-
AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
759
processed into HTML and manpages (e.g. git.html and git.1 in the
760
same directory).
761
···
44
uses (even if it doesn't match the overall style of existing code).
45
46
But if you must have a list of rules, here are some language
47
+
specific ones. Note that Documentation/ToolsForGit.adoc document
48
has a collection of tips to help you use some external tools
49
to conform to these guidelines.
50
···
755
Writing Documentation:
756
757
Most (if not all) of the documentation pages are written in the
758
+
AsciiDoc format in *.adoc files (e.g. Documentation/git.adoc), and
759
processed into HTML and manpages (e.g. git.html and git.1 in the
760
same directory).
761
+12
-12
Documentation/MyFirstContribution.adoc
+12
-12
Documentation/MyFirstContribution.adoc
···
21
useful additional context:
22
23
- `Documentation/SubmittingPatches`
24
-
- `Documentation/howto/new-command.txt`
25
26
[[getting-help]]
27
=== Getting Help
···
331
apply standard precedence rules. `git_config_get_string_tmp()` will look up
332
a specific key ("user.name") and give you the value. There are a number of
333
single-key lookup functions like this one; you can see them all (and more info
334
-
about how to use `git_config()`) in `Documentation/technical/api-config.txt`.
335
336
You should see that the name printed matches the one you see when you run:
337
···
461
462
Your new command is undocumented! Let's fix that.
463
464
-
Take a look at `Documentation/git-*.txt`. These are the manpages for the
465
subcommands that Git knows about. You can open these up and take a look to get
466
acquainted with the format, but then go ahead and make a new file
467
-
`Documentation/git-psuh.txt`. Like with most of the documentation in the Git
468
project, help pages are written with AsciiDoc (see CodingGuidelines, "Writing
469
Documentation" section). Use the following template to fill out your own
470
manpage:
···
543
That's because `-h` is a special case which your command should handle by
544
printing usage.
545
546
-
Take a look at `Documentation/technical/api-parse-options.txt`. This is a handy
547
tool for pulling out options you need to be able to handle, and it takes a
548
usage string.
549
···
1088
The one generated for `psuh` from the sample implementation looks like this:
1089
1090
----
1091
-
Documentation/git-psuh.txt | 40 +++++++++++++++++++++
1092
-
Makefile | 1 +
1093
-
builtin.h | 1 +
1094
-
builtin/psuh.c | 73 ++++++++++++++++++++++++++++++++++++++
1095
-
git.c | 1 +
1096
-
t/t9999-psuh-tutorial.sh | 12 +++++++
1097
6 files changed, 128 insertions(+)
1098
-
create mode 100644 Documentation/git-psuh.txt
1099
create mode 100644 builtin/psuh.c
1100
create mode 100755 t/t9999-psuh-tutorial.sh
1101
----
···
21
useful additional context:
22
23
- `Documentation/SubmittingPatches`
24
+
- `Documentation/howto/new-command.adoc`
25
26
[[getting-help]]
27
=== Getting Help
···
331
apply standard precedence rules. `git_config_get_string_tmp()` will look up
332
a specific key ("user.name") and give you the value. There are a number of
333
single-key lookup functions like this one; you can see them all (and more info
334
+
about how to use `git_config()`) in `Documentation/technical/api-config.adoc`.
335
336
You should see that the name printed matches the one you see when you run:
337
···
461
462
Your new command is undocumented! Let's fix that.
463
464
+
Take a look at `Documentation/git-*.adoc`. These are the manpages for the
465
subcommands that Git knows about. You can open these up and take a look to get
466
acquainted with the format, but then go ahead and make a new file
467
+
`Documentation/git-psuh.adoc`. Like with most of the documentation in the Git
468
project, help pages are written with AsciiDoc (see CodingGuidelines, "Writing
469
Documentation" section). Use the following template to fill out your own
470
manpage:
···
543
That's because `-h` is a special case which your command should handle by
544
printing usage.
545
546
+
Take a look at `Documentation/technical/api-parse-options.adoc`. This is a handy
547
tool for pulling out options you need to be able to handle, and it takes a
548
usage string.
549
···
1088
The one generated for `psuh` from the sample implementation looks like this:
1089
1090
----
1091
+
Documentation/git-psuh.adoc | 40 +++++++++++++++++++++
1092
+
Makefile | 1 +
1093
+
builtin.h | 1 +
1094
+
builtin/psuh.c | 73 ++++++++++++++++++++++++++++++++++++++
1095
+
git.c | 1 +
1096
+
t/t9999-psuh-tutorial.sh | 12 +++++++
1097
6 files changed, 128 insertions(+)
1098
+
create mode 100644 Documentation/git-psuh.adoc
1099
create mode 100644 builtin/psuh.c
1100
create mode 100755 t/t9999-psuh-tutorial.sh
1101
----
+6
-6
Documentation/MyFirstObjectWalk.adoc
+6
-6
Documentation/MyFirstObjectWalk.adoc
···
15
16
=== Related Reading
17
18
-
- `Documentation/user-manual.txt` under "Hacking Git" contains some coverage of
19
the revision walker in its various incarnations.
20
- `revision.h`
21
- https://eagain.net/articles/git-for-computer-scientists/[Git for Computer Scientists]
···
112
----
113
114
NOTE: For a more exhaustive overview of the new command process, take a look at
115
-
`Documentation/MyFirstContribution.txt`.
116
117
NOTE: A reference implementation can be found at
118
https://github.com/nasamuffin/git/tree/revwalk.
···
132
Per entry, we find:
133
134
`item` is the object provided upon which to base the object walk. Items in Git
135
-
can be blobs, trees, commits, or tags. (See `Documentation/gittutorial-2.txt`.)
136
137
`name` is the object ID (OID) of the object - a hex string you may be familiar
138
with from using Git to organize your source in the past. Check the tutorial
···
141
142
`whence` indicates some information about what to do with the parents of the
143
specified object. We'll explore this flag more later on; take a look at
144
-
`Documentation/revisions.txt` to get an idea of what could set the `whence`
145
value.
146
147
`flags` are used to hint the beginning of the revision walk and are the first
···
153
154
This one is quite a bit longer, and many fields are only used during the walk
155
by `revision.c` - not configuration options. Most of the configurable flags in
156
-
`struct rev_info` have a mirror in `Documentation/rev-list-options.txt`. It's a
157
good idea to take some time and read through that document.
158
159
== Basic Commit Walk
···
710
=== Adding a Filter
711
712
There are a handful of filters that we can apply to the object walk laid out in
713
-
`Documentation/rev-list-options.txt`. These filters are typically useful for
714
operations such as creating packfiles or performing a partial clone. They are
715
defined in `list-objects-filter-options.h`. For the purposes of this tutorial we
716
will use the "tree:1" filter, which causes the walk to omit all trees and blobs
···
15
16
=== Related Reading
17
18
+
- `Documentation/user-manual.adoc` under "Hacking Git" contains some coverage of
19
the revision walker in its various incarnations.
20
- `revision.h`
21
- https://eagain.net/articles/git-for-computer-scientists/[Git for Computer Scientists]
···
112
----
113
114
NOTE: For a more exhaustive overview of the new command process, take a look at
115
+
`Documentation/MyFirstContribution.adoc`.
116
117
NOTE: A reference implementation can be found at
118
https://github.com/nasamuffin/git/tree/revwalk.
···
132
Per entry, we find:
133
134
`item` is the object provided upon which to base the object walk. Items in Git
135
+
can be blobs, trees, commits, or tags. (See `Documentation/gittutorial-2.adoc`.)
136
137
`name` is the object ID (OID) of the object - a hex string you may be familiar
138
with from using Git to organize your source in the past. Check the tutorial
···
141
142
`whence` indicates some information about what to do with the parents of the
143
specified object. We'll explore this flag more later on; take a look at
144
+
`Documentation/revisions.adoc` to get an idea of what could set the `whence`
145
value.
146
147
`flags` are used to hint the beginning of the revision walk and are the first
···
153
154
This one is quite a bit longer, and many fields are only used during the walk
155
by `revision.c` - not configuration options. Most of the configurable flags in
156
+
`struct rev_info` have a mirror in `Documentation/rev-list-options.adoc`. It's a
157
good idea to take some time and read through that document.
158
159
== Basic Commit Walk
···
710
=== Adding a Filter
711
712
There are a handful of filters that we can apply to the object walk laid out in
713
+
`Documentation/rev-list-options.adoc`. These filters are typically useful for
714
operations such as creating packfiles or performing a partial clone. They are
715
defined in `list-objects-filter-options.h`. For the purposes of this tutorial we
716
will use the "tree:1" filter, which causes the walk to omit all trees and blobs
+12
-12
Documentation/build-docdep.perl
+12
-12
Documentation/build-docdep.perl
···
4
my %include = ();
5
my %included = ();
6
7
-
for my $text (<*.txt>) {
8
-
open I, '<', $text || die "cannot read: $text";
9
while (<I>) {
10
if (/^include::/) {
11
chomp;
12
s/^include::\s*//;
13
s/\[\]//;
14
s/{build_dir}/${build_dir}/;
15
-
$include{$text}{$_} = 1;
16
$included{$_} = 1;
17
}
18
}
···
23
my $changed = 1;
24
while ($changed) {
25
$changed = 0;
26
-
while (my ($text, $included) = each %include) {
27
for my $i (keys %$included) {
28
-
# $text has include::$i; if $i includes $j
29
-
# $text indirectly includes $j.
30
if (exists $include{$i}) {
31
for my $j (keys %{$include{$i}}) {
32
-
if (!exists $include{$text}{$j}) {
33
-
$include{$text}{$j} = 1;
34
$included{$j} = 1;
35
$changed = 1;
36
}
···
40
}
41
}
42
43
-
foreach my $text (sort keys %include) {
44
-
my $included = $include{$text};
45
-
if (! exists $included{$text} &&
46
-
(my $base = $text) =~ s/\.txt$//) {
47
print "$base.html $base.xml : ", join(" ", sort keys %$included), "\n";
48
}
49
}
···
4
my %include = ();
5
my %included = ();
6
7
+
for my $adoc (<*.adoc>) {
8
+
open I, '<', $adoc || die "cannot read: $adoc";
9
while (<I>) {
10
if (/^include::/) {
11
chomp;
12
s/^include::\s*//;
13
s/\[\]//;
14
s/{build_dir}/${build_dir}/;
15
+
$include{$adoc}{$_} = 1;
16
$included{$_} = 1;
17
}
18
}
···
23
my $changed = 1;
24
while ($changed) {
25
$changed = 0;
26
+
while (my ($adoc, $included) = each %include) {
27
for my $i (keys %$included) {
28
+
# $adoc has include::$i; if $i includes $j
29
+
# $adoc indirectly includes $j.
30
if (exists $include{$i}) {
31
for my $j (keys %{$include{$i}}) {
32
+
if (!exists $include{$adoc}{$j}) {
33
+
$include{$adoc}{$j} = 1;
34
$included{$j} = 1;
35
$changed = 1;
36
}
···
40
}
41
}
42
43
+
foreach my $adoc (sort keys %include) {
44
+
my $included = $include{$adoc};
45
+
if (! exists $included{$adoc} &&
46
+
(my $base = $adoc) =~ s/\.adoc$//) {
47
print "$base.html $base.xml : ", join(" ", sort keys %$included), "\n";
48
}
49
}
+3
-3
Documentation/gitattributes.adoc
+3
-3
Documentation/gitattributes.adoc
···
513
`filter.<driver>.process` then Git can process all blobs with a
514
single filter invocation for the entire life of a single Git
515
command. This is achieved by using the long-running process protocol
516
-
(described in technical/long-running-process-protocol.txt).
517
518
When Git encounters the first file that needs to be cleaned or smudged,
519
it starts the filter and performs the handshake. In the handshake, the
···
1177
1178
For example, this line in `.gitattributes` can be used to tell the merge
1179
machinery to leave much longer (instead of the usual 7-character-long)
1180
-
conflict markers when merging the file `Documentation/git-merge.txt`
1181
results in a conflict.
1182
1183
------------------------
1184
-
Documentation/git-merge.txt conflict-marker-size=32
1185
------------------------
1186
1187
···
513
`filter.<driver>.process` then Git can process all blobs with a
514
single filter invocation for the entire life of a single Git
515
command. This is achieved by using the long-running process protocol
516
+
(described in Documentation/technical/long-running-process-protocol.adoc).
517
518
When Git encounters the first file that needs to be cleaned or smudged,
519
it starts the filter and performs the handshake. In the handshake, the
···
1177
1178
For example, this line in `.gitattributes` can be used to tell the merge
1179
machinery to leave much longer (instead of the usual 7-character-long)
1180
+
conflict markers when merging the file `Documentation/git-merge.adoc`
1181
results in a conflict.
1182
1183
------------------------
1184
+
Documentation/git-merge.adoc conflict-marker-size=32
1185
------------------------
1186
1187
+7
-7
Documentation/howto/howto-index.sh
+7
-7
Documentation/howto/howto-index.sh
···
9
10
EOF
11
12
-
for txt
13
do
14
-
title=$(expr "$txt" : '.*/\(.*\)\.txt$')
15
from=$(sed -ne '
16
/^$/q
17
/^From:[ ]/{
···
21
s/^/by /
22
p
23
}
24
-
' "$txt")
25
26
abstract=$(sed -ne '
27
/^Abstract:[ ]/{
···
39
x
40
p
41
q
42
-
}' "$txt")
43
44
-
if grep 'Content-type: text/asciidoc' >/dev/null $txt
45
then
46
-
file=$(expr "$txt" : '\(.*\)\.txt$').html
47
else
48
-
file="$txt"
49
fi
50
51
echo "* link:howto/$(basename "$file")[$title] $from
···
9
10
EOF
11
12
+
for adoc
13
do
14
+
title=$(expr "$adoc" : '.*/\(.*\)\.adoc$')
15
from=$(sed -ne '
16
/^$/q
17
/^From:[ ]/{
···
21
s/^/by /
22
p
23
}
24
+
' "$adoc")
25
26
abstract=$(sed -ne '
27
/^Abstract:[ ]/{
···
39
x
40
p
41
q
42
+
}' "$adoc")
43
44
+
if grep 'Content-type: text/asciidoc' >/dev/null $adoc
45
then
46
+
file=$(expr "$adoc" : '\(.*\)\.adoc$').html
47
else
48
+
file="$adoc"
49
fi
50
51
echo "* link:howto/$(basename "$file")[$title] $from
+1
-1
Documentation/howto/new-command.adoc
+1
-1
Documentation/howto/new-command.adoc
+1
-1
Documentation/technical/api-simple-ipc.adoc
+1
-1
Documentation/technical/api-simple-ipc.adoc
···
36
---------------------------------
37
38
The Simple-IPC mechanism differs from the existing `sub-process.c`
39
-
model (Documentation/technical/long-running-process-protocol.txt) and
40
used by applications like Git-LFS. In the LFS-style sub-process model,
41
the helper is started by the foreground process, communication happens
42
via a pair of file descriptors bound to the stdin/stdout of the
···
36
---------------------------------
37
38
The Simple-IPC mechanism differs from the existing `sub-process.c`
39
+
model (Documentation/technical/long-running-process-protocol.adoc) and
40
used by applications like Git-LFS. In the LFS-style sub-process model,
41
the helper is started by the foreground process, communication happens
42
via a pair of file descriptors bound to the stdin/stdout of the
+1
-1
Documentation/technical/hash-function-transition.adoc
+1
-1
Documentation/technical/hash-function-transition.adoc
···
394
395
Step 4 is probably necessary for good read-time performance. "git
396
pack-objects" on the server optimizes the pack file for good data
397
-
locality (see Documentation/technical/pack-heuristics.txt).
398
399
Details of this process are likely to change. It will take some
400
experimenting to get this to perform well.
···
394
395
Step 4 is probably necessary for good read-time performance. "git
396
pack-objects" on the server optimizes the pack file for good data
397
+
locality (see Documentation/technical/pack-heuristics.adoc).
398
399
Details of this process are likely to change. It will take some
400
experimenting to get this to perform well.
+1
-1
Documentation/technical/partial-clone.adoc
+1
-1
Documentation/technical/partial-clone.adoc
···
85
server to request filtering during packfile construction.
86
+
87
There are various filters available to accommodate different situations.
88
-
See "--filter=<filter-spec>" in Documentation/rev-list-options.txt.
89
90
- On the server pack-objects applies the requested filter-spec as it
91
creates "filtered" packfiles for the client.
···
85
server to request filtering during packfile construction.
86
+
87
There are various filters available to accommodate different situations.
88
+
See "--filter=<filter-spec>" in Documentation/rev-list-options.adoc.
89
90
- On the server pack-objects applies the requested filter-spec as it
91
creates "filtered" packfiles for the client.
+1
-1
Makefile
+1
-1
Makefile
···
194
# Linux, kernel 2.6.11 or newer is required for reliable sub-second file times
195
# on file systems with exactly 1 ns or 1 s resolution. If you intend to use Git
196
# on other file systems (e.g. CEPH, CIFS, NTFS, UDF), don't enable USE_NSEC. See
197
-
# Documentation/technical/racy-git.txt for details.
198
#
199
# Define USE_ST_TIMESPEC if your "struct stat" uses "st_ctimespec" instead of
200
# "st_ctim"
···
194
# Linux, kernel 2.6.11 or newer is required for reliable sub-second file times
195
# on file systems with exactly 1 ns or 1 s resolution. If you intend to use Git
196
# on other file systems (e.g. CEPH, CIFS, NTFS, UDF), don't enable USE_NSEC. See
197
+
# Documentation/technical/racy-git.adoc for details.
198
#
199
# Define USE_ST_TIMESPEC if your "struct stat" uses "st_ctimespec" instead of
200
# "st_ctim"
+7
-7
README.md
+7
-7
README.md
···
17
Many Git online resources are accessible from <https://git-scm.com/>
18
including full documentation and Git related tools.
19
20
-
See [Documentation/gittutorial.txt][] to get started, then see
21
-
[Documentation/giteveryday.txt][] for a useful minimum set of commands, and
22
-
`Documentation/git-<commandname>.txt` for documentation of each command.
23
If git has been correctly installed, then the tutorial can also be
24
read with `man gittutorial` or `git help tutorial`, and the
25
documentation of each command with `man git-<commandname>` or `git help
26
<commandname>`.
27
28
-
CVS users may also want to read [Documentation/gitcvs-migration.txt][]
29
(`man gitcvs-migration` or `git help cvs-migration` if git is
30
installed).
31
···
66
- "goddamn idiotic truckload of sh*t": when it breaks
67
68
[INSTALL]: INSTALL
69
-
[Documentation/gittutorial.txt]: Documentation/gittutorial.txt
70
-
[Documentation/giteveryday.txt]: Documentation/giteveryday.txt
71
-
[Documentation/gitcvs-migration.txt]: Documentation/gitcvs-migration.txt
72
[Documentation/SubmittingPatches]: Documentation/SubmittingPatches
73
[Documentation/CodingGuidelines]: Documentation/CodingGuidelines
74
[po/README.md]: po/README.md
···
17
Many Git online resources are accessible from <https://git-scm.com/>
18
including full documentation and Git related tools.
19
20
+
See [Documentation/gittutorial.adoc][] to get started, then see
21
+
[Documentation/giteveryday.adoc][] for a useful minimum set of commands, and
22
+
`Documentation/git-<commandname>.adoc` for documentation of each command.
23
If git has been correctly installed, then the tutorial can also be
24
read with `man gittutorial` or `git help tutorial`, and the
25
documentation of each command with `man git-<commandname>` or `git help
26
<commandname>`.
27
28
+
CVS users may also want to read [Documentation/gitcvs-migration.adoc][]
29
(`man gitcvs-migration` or `git help cvs-migration` if git is
30
installed).
31
···
66
- "goddamn idiotic truckload of sh*t": when it breaks
67
68
[INSTALL]: INSTALL
69
+
[Documentation/gittutorial.adoc]: Documentation/gittutorial.adoc
70
+
[Documentation/giteveryday.adoc]: Documentation/giteveryday.adoc
71
+
[Documentation/gitcvs-migration.adoc]: Documentation/gitcvs-migration.adoc
72
[Documentation/SubmittingPatches]: Documentation/SubmittingPatches
73
[Documentation/CodingGuidelines]: Documentation/CodingGuidelines
74
[po/README.md]: po/README.md
+1
-1
advice.h
+1
-1
advice.h
+1
-1
apply.c
+1
-1
apply.c
+1
-1
builtin.h
+1
-1
builtin.h
+8
-8
config.c
+8
-8
config.c
···
1647
return 0;
1648
}
1649
1650
-
/* Add other config variables here and to Documentation/config.txt. */
1651
return platform_core_config(var, value, ctx, cb);
1652
}
1653
···
1658
return 0;
1659
}
1660
1661
-
/* Add other config variables here and to Documentation/config/sparse.txt. */
1662
return 0;
1663
}
1664
···
1674
return git_config_string(&git_log_output_encoding, var, value);
1675
}
1676
1677
-
/* Add other config variables here and to Documentation/config.txt. */
1678
return 0;
1679
}
1680
···
1710
return 0;
1711
}
1712
1713
-
/* Add other config variables here and to Documentation/config.txt. */
1714
return 0;
1715
}
1716
···
1739
return 0;
1740
}
1741
1742
-
/* Add other config variables here and to Documentation/config.txt. */
1743
return 0;
1744
}
1745
···
1755
return git_config_string(&git_mailmap_blob, var, value);
1756
}
1757
1758
-
/* Add other config variables here and to Documentation/config.txt. */
1759
return 0;
1760
}
1761
···
1768
1769
/*
1770
* Add other attribute related config variables here and to
1771
-
* Documentation/config/attr.txt.
1772
*/
1773
return 0;
1774
}
···
1826
if (starts_with(var, "sparse."))
1827
return git_default_sparse_config(var, value);
1828
1829
-
/* Add other config variables here and to Documentation/config.txt. */
1830
return 0;
1831
}
1832
···
1647
return 0;
1648
}
1649
1650
+
/* Add other config variables here and to Documentation/config.adoc. */
1651
return platform_core_config(var, value, ctx, cb);
1652
}
1653
···
1658
return 0;
1659
}
1660
1661
+
/* Add other config variables here and to Documentation/config/sparse.adoc. */
1662
return 0;
1663
}
1664
···
1674
return git_config_string(&git_log_output_encoding, var, value);
1675
}
1676
1677
+
/* Add other config variables here and to Documentation/config.adoc. */
1678
return 0;
1679
}
1680
···
1710
return 0;
1711
}
1712
1713
+
/* Add other config variables here and to Documentation/config.adoc. */
1714
return 0;
1715
}
1716
···
1739
return 0;
1740
}
1741
1742
+
/* Add other config variables here and to Documentation/config.adoc. */
1743
return 0;
1744
}
1745
···
1755
return git_config_string(&git_mailmap_blob, var, value);
1756
}
1757
1758
+
/* Add other config variables here and to Documentation/config.adoc. */
1759
return 0;
1760
}
1761
···
1768
1769
/*
1770
* Add other attribute related config variables here and to
1771
+
* Documentation/config/attr.adoc.
1772
*/
1773
return 0;
1774
}
···
1826
if (starts_with(var, "sparse."))
1827
return git_default_sparse_config(var, value);
1828
1829
+
/* Add other config variables here and to Documentation/config.adoc. */
1830
return 0;
1831
}
1832
+1
-1
contrib/contacts/Makefile
+1
-1
contrib/contacts/Makefile
contrib/contacts/git-contacts.txt
contrib/contacts/git-contacts.adoc
contrib/contacts/git-contacts.txt
contrib/contacts/git-contacts.adoc
+2
-2
contrib/contacts/meson.build
+2
-2
contrib/contacts/meson.build
···
16
'@INPUT@',
17
],
18
depends: documentation_deps,
19
-
input: 'git-contacts.txt',
20
output: 'git-contacts.xml',
21
)
22
···
47
'@INPUT@',
48
],
49
depends: documentation_deps,
50
-
input: 'git-contacts.txt',
51
output: 'git-contacts.html',
52
install: true,
53
install_dir: get_option('datadir') / 'doc/git-doc',
···
16
'@INPUT@',
17
],
18
depends: documentation_deps,
19
+
input: 'git-contacts.adoc',
20
output: 'git-contacts.xml',
21
)
22
···
47
'@INPUT@',
48
],
49
depends: documentation_deps,
50
+
input: 'git-contacts.adoc',
51
output: 'git-contacts.html',
52
install: true,
53
install_dir: get_option('datadir') / 'doc/git-doc',
+1
-1
contrib/long-running-filter/example.pl
+1
-1
contrib/long-running-filter/example.pl
+1
-1
contrib/subtree/Makefile
+1
-1
contrib/subtree/Makefile
contrib/subtree/git-subtree.txt
contrib/subtree/git-subtree.adoc
contrib/subtree/git-subtree.txt
contrib/subtree/git-subtree.adoc
+2
-2
contrib/subtree/meson.build
+2
-2
contrib/subtree/meson.build
···
32
'@INPUT@',
33
],
34
depends: documentation_deps,
35
-
input: 'git-subtree.txt',
36
output: 'git-subtree.xml',
37
)
38
···
63
'@INPUT@',
64
],
65
depends: documentation_deps,
66
-
input: 'git-subtree.txt',
67
output: 'git-subtree.html',
68
install: true,
69
install_dir: get_option('datadir') / 'doc/git-doc',
···
32
'@INPUT@',
33
],
34
depends: documentation_deps,
35
+
input: 'git-subtree.adoc',
36
output: 'git-subtree.xml',
37
)
38
···
63
'@INPUT@',
64
],
65
depends: documentation_deps,
66
+
input: 'git-subtree.adoc',
67
output: 'git-subtree.html',
68
install: true,
69
install_dir: get_option('datadir') / 'doc/git-doc',
+1
-1
diff.h
+1
-1
diff.h
+1
-1
diffcore.h
+1
-1
diffcore.h
+1
-1
fsck.h
+1
-1
fsck.h
+1
-1
list-objects-filter-options.h
+1
-1
list-objects-filter-options.h
···
82
* "filter" SP <arg>
83
*
84
* The filter keyword will be used by many commands.
85
-
* See Documentation/rev-list-options.txt for allowed values for <arg>.
86
*
87
* Capture the given arg as the "filter_spec". This can be forwarded to
88
* subordinate commands when necessary (although it's better to pass it through
···
82
* "filter" SP <arg>
83
*
84
* The filter keyword will be used by many commands.
85
+
* See Documentation/rev-list-options.adoc for allowed values for <arg>.
86
*
87
* Capture the given arg as the "filter_spec". This can be forwarded to
88
* subordinate commands when necessary (although it's better to pass it through
+1
-1
object-name.c
+1
-1
object-name.c
+1
-1
parse-options.h
+1
-1
parse-options.h
+1
-1
pseudo-merge.h
+1
-1
pseudo-merge.h
+1
-1
refs.h
+1
-1
refs.h
···
577
578
/*
579
* Return 0 iff refname has the correct format for a refname according
580
-
* to the rules described in Documentation/git-check-ref-format.txt.
581
* If REFNAME_ALLOW_ONELEVEL is set in flags, then accept one-level
582
* reference names. If REFNAME_REFSPEC_PATTERN is set in flags, then
583
* allow a single "*" wildcard character in the refspec. No leading or
···
577
578
/*
579
* Return 0 iff refname has the correct format for a refname according
580
+
* to the rules described in Documentation/git-check-ref-format.adoc.
581
* If REFNAME_ALLOW_ONELEVEL is set in flags, then accept one-level
582
* reference names. If REFNAME_REFSPEC_PATTERN is set in flags, then
583
* allow a single "*" wildcard character in the refspec. No leading or
+1
-1
setup.c
+1
-1
setup.c
+1
-1
simple-ipc.h
+1
-1
simple-ipc.h
+1
-1
t/helper/test-rot13-filter.c
+1
-1
t/helper/test-rot13-filter.c
+25
-25
t/t0450-txt-doc-vs-help.sh
+25
-25
t/t0450-txt-doc-vs-help.sh
···
1
#!/bin/sh
2
3
-
test_description='assert (unbuilt) Documentation/*.txt and -h output
4
5
Run this with --debug to see a summary of where we still fail to make
6
the two versions consistent with one another.'
···
11
git --list-cmds=builtins >builtins
12
'
13
14
-
test_expect_success 'list of txt and help mismatches is sorted' '
15
-
sort -u "$TEST_DIRECTORY"/t0450/txt-help-mismatches >expect &&
16
-
if ! test_cmp expect "$TEST_DIRECTORY"/t0450/txt-help-mismatches
17
then
18
-
BUG "please keep the list of txt and help mismatches sorted"
19
fi
20
'
21
···
40
echo "$out"
41
}
42
43
-
builtin_to_txt () {
44
-
echo "$GIT_BUILD_DIR/Documentation/git-$1.txt"
45
}
46
47
-
txt_to_synopsis () {
48
builtin="$1" &&
49
out_dir="out/$builtin" &&
50
-
out="$out_dir/txt.synopsis" &&
51
if test -f "$out"
52
then
53
echo "$out" &&
54
return 0
55
fi &&
56
-
b2t="$(builtin_to_txt "$builtin")" &&
57
sed -n \
58
-E '/^\[(verse|synopsis)\]$/,/^$/ {
59
/^$/d;
···
109
fi
110
'
111
112
-
txt="$(builtin_to_txt "$builtin")" &&
113
-
preq="$(echo BUILTIN_TXT_$builtin | tr '[:lower:]-' '[:upper:]_')" &&
114
115
-
if test -f "$txt"
116
then
117
test_set_prereq "$preq"
118
fi &&
119
120
-
# *.txt output assertions
121
-
test_expect_success "$preq" "$builtin *.txt SYNOPSIS has dashed labels" '
122
-
check_dashed_labels "$(txt_to_synopsis "$builtin")"
123
'
124
125
-
# *.txt output consistency assertions
126
result=
127
-
if grep -q "^$builtin$" "$TEST_DIRECTORY"/t0450/txt-help-mismatches
128
then
129
result=failure
130
else
131
result=success
132
fi &&
133
test_expect_$result "$preq" "$builtin -h output and SYNOPSIS agree" '
134
-
t2s="$(txt_to_synopsis "$builtin")" &&
135
if test "$builtin" = "merge-tree"
136
then
137
test_when_finished "rm -f t2s.new" &&
···
140
fi &&
141
h2s="$(help_to_synopsis "$builtin")" &&
142
143
-
# The *.txt and -h use different spacing for the
144
# alignment of continued usage output, normalize it.
145
-
align_after_nl "$builtin" <"$t2s" >txt &&
146
align_after_nl "$builtin" <"$h2s" >help &&
147
-
test_cmp txt help
148
'
149
150
-
if test_have_prereq "$preq" && test -e txt && test -e help
151
then
152
test_debug '
153
-
if test_cmp txt help >cmp 2>/dev/null
154
then
155
echo "=== DONE: $builtin ==="
156
else
···
161
162
# Not in test_expect_success in case --run is being
163
# used with --debug
164
-
rm -f txt help tmp 2>/dev/null
165
fi
166
done <builtins
167
···
1
#!/bin/sh
2
3
+
test_description='assert (unbuilt) Documentation/*.adoc and -h output
4
5
Run this with --debug to see a summary of where we still fail to make
6
the two versions consistent with one another.'
···
11
git --list-cmds=builtins >builtins
12
'
13
14
+
test_expect_success 'list of adoc and help mismatches is sorted' '
15
+
sort -u "$TEST_DIRECTORY"/t0450/adoc-help-mismatches >expect &&
16
+
if ! test_cmp expect "$TEST_DIRECTORY"/t0450/adoc-help-mismatches
17
then
18
+
BUG "please keep the list of adoc and help mismatches sorted"
19
fi
20
'
21
···
40
echo "$out"
41
}
42
43
+
builtin_to_adoc () {
44
+
echo "$GIT_BUILD_DIR/Documentation/git-$1.adoc"
45
}
46
47
+
adoc_to_synopsis () {
48
builtin="$1" &&
49
out_dir="out/$builtin" &&
50
+
out="$out_dir/adoc.synopsis" &&
51
if test -f "$out"
52
then
53
echo "$out" &&
54
return 0
55
fi &&
56
+
b2t="$(builtin_to_adoc "$builtin")" &&
57
sed -n \
58
-E '/^\[(verse|synopsis)\]$/,/^$/ {
59
/^$/d;
···
109
fi
110
'
111
112
+
adoc="$(builtin_to_adoc "$builtin")" &&
113
+
preq="$(echo BUILTIN_ADOC_$builtin | tr '[:lower:]-' '[:upper:]_')" &&
114
115
+
if test -f "$adoc"
116
then
117
test_set_prereq "$preq"
118
fi &&
119
120
+
# *.adoc output assertions
121
+
test_expect_success "$preq" "$builtin *.adoc SYNOPSIS has dashed labels" '
122
+
check_dashed_labels "$(adoc_to_synopsis "$builtin")"
123
'
124
125
+
# *.adoc output consistency assertions
126
result=
127
+
if grep -q "^$builtin$" "$TEST_DIRECTORY"/t0450/adoc-help-mismatches
128
then
129
result=failure
130
else
131
result=success
132
fi &&
133
test_expect_$result "$preq" "$builtin -h output and SYNOPSIS agree" '
134
+
t2s="$(adoc_to_synopsis "$builtin")" &&
135
if test "$builtin" = "merge-tree"
136
then
137
test_when_finished "rm -f t2s.new" &&
···
140
fi &&
141
h2s="$(help_to_synopsis "$builtin")" &&
142
143
+
# The *.adoc and -h use different spacing for the
144
# alignment of continued usage output, normalize it.
145
+
align_after_nl "$builtin" <"$t2s" >adoc &&
146
align_after_nl "$builtin" <"$h2s" >help &&
147
+
test_cmp adoc help
148
'
149
150
+
if test_have_prereq "$preq" && test -e adoc && test -e help
151
then
152
test_debug '
153
+
if test_cmp adoc help >cmp 2>/dev/null
154
then
155
echo "=== DONE: $builtin ==="
156
else
···
161
162
# Not in test_expect_success in case --run is being
163
# used with --debug
164
+
rm -f adoc help tmp 2>/dev/null
165
fi
166
done <builtins
167
t/t0450/txt-help-mismatches
t/t0450/adoc-help-mismatches
t/t0450/txt-help-mismatches
t/t0450/adoc-help-mismatches
+1
-1
t/t6012-rev-list-simplify.sh
+1
-1
t/t6012-rev-list-simplify.sh
+1
-1
t/t6434-merge-recursive-rename-options.sh
+1
-1
t/t6434-merge-recursive-rename-options.sh
+1
-1
trace2.h
+1
-1
trace2.h
+1
-1
trace2/tr2_sysenv.c
+1
-1
trace2/tr2_sysenv.c
+1
-1
transport.h
+1
-1
transport.h
···
168
* Check whether a transport is allowed by the environment.
169
*
170
* Type should generally be the URL scheme, as described in
171
-
* Documentation/git.txt
172
*
173
* from_user specifies if the transport was given by the user. If unknown pass
174
* a -1 to read from the environment to determine if the transport was given by
···
168
* Check whether a transport is allowed by the environment.
169
*
170
* Type should generally be the URL scheme, as described in
171
+
* Documentation/git.adoc
172
*
173
* from_user specifies if the transport was given by the user. If unknown pass
174
* a -1 to read from the environment to determine if the transport was given by
+1
-1
unpack-trees.c
+1
-1
unpack-trees.c
···
2904
* The rule is to "carry forward" what is in the index without losing
2905
* information across a "fast-forward", favoring a successful merge
2906
* over a merge failure when it makes sense. For details of the
2907
-
* "carry forward" rule, please see <Documentation/git-read-tree.txt>.
2908
*
2909
*/
2910
int twoway_merge(const struct cache_entry * const *src,
···
2904
* The rule is to "carry forward" what is in the index without losing
2905
* information across a "fast-forward", favoring a successful merge
2906
* over a merge failure when it makes sense. For details of the
2907
+
* "carry forward" rule, please see <Documentation/git-read-tree.adoc>.
2908
*
2909
*/
2910
int twoway_merge(const struct cache_entry * const *src,
+1
-1
xdiff/xdiff.h
+1
-1
xdiff/xdiff.h
+1
-1
xdiff/xpatience.c
+1
-1
xdiff/xpatience.c