freshlybakedca.ke
Git fork
doc: fix some typos, grammar and wording issues
Signed-off-by: Štěpán Němec <stepnem@smrk.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
authored by
Štěpán Němec
and committed by
Junio C Hamano
97509a34
3a06386e
+5
-5
Documentation/SubmittingPatches
+5
-5
Documentation/SubmittingPatches
···
393
394
Learn to use format-patch and send-email if possible. These commands
395
are optimized for the workflow of sending patches, avoiding many ways
396
-
your existing e-mail client that is optimized for "multipart/*" mime
397
-
type e-mails to corrupt and render your patches unusable.
398
399
People on the Git mailing list need to be able to read and
400
comment on the changes you are submitting. It is important for
···
515
516
git://git.ozlabs.org/~paulus/gitk
517
518
-
Those who are interested in improve gitk can volunteer to help Paul
519
-
in maintaining it cf. <YntxL/fTplFm8lr6@cleo>.
520
521
- `po/` comes from the localization coordinator, Jiang Xin:
522
···
556
557
In any time between the (2)-(3) cycle, the maintainer may pick it up
558
from the list and queue it to `seen`, in order to make it easier for
559
-
people play with it without having to pick up and apply the patch to
560
their trees themselves.
561
562
[[patch-status]]
···
393
394
Learn to use format-patch and send-email if possible. These commands
395
are optimized for the workflow of sending patches, avoiding many ways
396
+
your existing e-mail client (often optimized for "multipart/*" MIME
397
+
type e-mails) might render your patches unusable.
398
399
People on the Git mailing list need to be able to read and
400
comment on the changes you are submitting. It is important for
···
515
516
git://git.ozlabs.org/~paulus/gitk
517
518
+
Those who are interested in improving gitk can volunteer to help Paul
519
+
maintain it, cf. <YntxL/fTplFm8lr6@cleo>.
520
521
- `po/` comes from the localization coordinator, Jiang Xin:
522
···
556
557
In any time between the (2)-(3) cycle, the maintainer may pick it up
558
from the list and queue it to `seen`, in order to make it easier for
559
+
people to play with it without having to pick up and apply the patch to
560
their trees themselves.
561
562
[[patch-status]]
+1
-1
Documentation/config/transfer.txt
+1
-1
Documentation/config/transfer.txt
···
21
system.
22
* The git programs will pass the full URL to one another as arguments
23
on the command-line, meaning the credentials will be exposed to other
24
-
users on OS's or systems that allow other users to see the full
25
process list of other users. On linux the "hidepid" setting
26
documented in procfs(5) allows for configuring this behavior.
27
+
···
21
system.
22
* The git programs will pass the full URL to one another as arguments
23
on the command-line, meaning the credentials will be exposed to other
24
+
unprivileged users on systems that allow them to see the full
25
process list of other users. On linux the "hidepid" setting
26
documented in procfs(5) allows for configuring this behavior.
27
+
+1
-1
Documentation/diff-options.txt
+1
-1
Documentation/diff-options.txt
+1
-1
Documentation/git-branch.txt
+1
-1
Documentation/git-branch.txt
···
324
multiple times, in which case the last key becomes the primary
325
key. The keys supported are the same as those in `git
326
for-each-ref`. Sort order defaults to the value configured for the
327
-
`branch.sort` variable if exists, or to sorting based on the
328
full refname (including `refs/...` prefix). This lists
329
detached HEAD (if present) first, then local branches and
330
finally remote-tracking branches. See linkgit:git-config[1].
···
324
multiple times, in which case the last key becomes the primary
325
key. The keys supported are the same as those in `git
326
for-each-ref`. Sort order defaults to the value configured for the
327
+
`branch.sort` variable if it exists, or to sorting based on the
328
full refname (including `refs/...` prefix). This lists
329
detached HEAD (if present) first, then local branches and
330
finally remote-tracking branches. See linkgit:git-config[1].
+1
-1
Documentation/git-range-diff.txt
+1
-1
Documentation/git-range-diff.txt
···
166
167
In this example, there are 3 old and 3 new commits, where the developer
168
removed the 3rd, added a new one before the first two, and modified the
169
-
commit message of the 2nd commit as well its diff.
170
171
When the output goes to a terminal, it is color-coded by default, just
172
like regular `git diff`'s output. In addition, the first line (adding a
···
166
167
In this example, there are 3 old and 3 new commits, where the developer
168
removed the 3rd, added a new one before the first two, and modified the
169
+
commit message of the 2nd commit as well as its diff.
170
171
When the output goes to a terminal, it is color-coded by default, just
172
like regular `git diff`'s output. In addition, the first line (adding a
+3
-3
Documentation/git.txt
+3
-3
Documentation/git.txt
···
96
to avoid ambiguity with `<name>` containing one.
97
+
98
This is useful for cases where you want to pass transitory
99
-
configuration options to git, but are doing so on OS's where
100
-
other processes might be able to read your cmdline
101
-
(e.g. `/proc/self/cmdline`), but not your environ
102
(e.g. `/proc/self/environ`). That behavior is the default on
103
Linux, but may not be on your system.
104
+
···
96
to avoid ambiguity with `<name>` containing one.
97
+
98
This is useful for cases where you want to pass transitory
99
+
configuration options to git, but are doing so on operating systems
100
+
where other processes might be able to read your command line
101
+
(e.g. `/proc/self/cmdline`), but not your environment
102
(e.g. `/proc/self/environ`). That behavior is the default on
103
Linux, but may not be on your system.
104
+
+2
-2
Documentation/gitattributes.txt
+2
-2
Documentation/gitattributes.txt
···
1151
^^^^^^^^^^^^^^^^^^^^^^
1152
1153
This attribute controls the length of conflict markers left in
1154
-
the work tree file during a conflicted merge. Only setting to
1155
-
the value to a positive integer has any meaningful effect.
1156
1157
For example, this line in `.gitattributes` can be used to tell the merge
1158
machinery to leave much longer (instead of the usual 7-character-long)
···
1151
^^^^^^^^^^^^^^^^^^^^^^
1152
1153
This attribute controls the length of conflict markers left in
1154
+
the work tree file during a conflicted merge. Only a positive
1155
+
integer has a meaningful effect.
1156
1157
For example, this line in `.gitattributes` can be used to tell the merge
1158
machinery to leave much longer (instead of the usual 7-character-long)
+1
-1
Documentation/giteveryday.txt
+1
-1
Documentation/giteveryday.txt
+2
-2
contrib/README
+2
-2
contrib/README
···
23
lesser degree various foreign SCM interfaces, so you know the
24
drill.
25
26
-
I expect that things that start their life in the contrib/ area
27
to graduate out of contrib/ once they mature, either by becoming
28
projects on their own, or moving to the toplevel directory. On
29
the other hand, I expect I'll be proposing removal of disused
···
31
32
If you have new things to add to this area, please first propose
33
it on the git mailing list, and after a list discussion proves
34
-
there are some general interests (it does not have to be a
35
list-wide consensus for a tool targeted to a relatively narrow
36
audience -- for example I do not work with projects whose
37
upstream is svn, so I have no use for git-svn myself, but it is
···
23
lesser degree various foreign SCM interfaces, so you know the
24
drill.
25
26
+
I expect things that start their life in the contrib/ area
27
to graduate out of contrib/ once they mature, either by becoming
28
projects on their own, or moving to the toplevel directory. On
29
the other hand, I expect I'll be proposing removal of disused
···
31
32
If you have new things to add to this area, please first propose
33
it on the git mailing list, and after a list discussion proves
34
+
there is general interest (it does not have to be a
35
list-wide consensus for a tool targeted to a relatively narrow
36
audience -- for example I do not work with projects whose
37
upstream is svn, so I have no use for git-svn myself, but it is
+1
-1
fsmonitor--daemon.h
+1
-1
fsmonitor--daemon.h
···
99
* to only mean an external GITDIR referenced by a ".git" file.
100
*
101
* The platform FS event backends will receive watch-specific
102
-
* relative paths (except for those OS's that always emit absolute
103
* paths). We use the following enum and routines to classify each
104
* path so that we know how to handle it. There is a slight asymmetry
105
* here because ".git/" is inside the working directory and the
···
99
* to only mean an external GITDIR referenced by a ".git" file.
100
*
101
* The platform FS event backends will receive watch-specific
102
+
* relative paths (except for those OSes that always emit absolute
103
* paths). We use the following enum and routines to classify each
104
* path so that we know how to handle it. There is a slight asymmetry
105
* here because ".git/" is inside the working directory and the
+4
-4
strbuf.h
+4
-4
strbuf.h
···
12
struct string_list;
13
14
/**
15
-
* strbuf's are meant to be used with all the usual C string and memory
16
* APIs. Given that the length of the buffer is known, it's often better to
17
-
* use the mem* functions than a str* one (memchr vs. strchr e.g.).
18
* Though, one has to be careful about the fact that str* functions often
19
* stop on NULs and that strbufs may have embedded NULs.
20
*
···
24
* strbufs have some invariants that are very important to keep in mind:
25
*
26
* - The `buf` member is never NULL, so it can be used in any usual C
27
-
* string operations safely. strbuf's _have_ to be initialized either by
28
* `strbuf_init()` or by `= STRBUF_INIT` before the invariants, though.
29
*
30
* Do *not* assume anything on what `buf` really is (e.g. if it is
···
37
*
38
* - The `buf` member is a byte array that has at least `len + 1` bytes
39
* allocated. The extra byte is used to store a `'\0'`, allowing the
40
-
* `buf` member to be a valid C-string. Every strbuf function ensure this
41
* invariant is preserved.
42
*
43
* NOTE: It is OK to "play" with the buffer directly if you work it this
···
12
struct string_list;
13
14
/**
15
+
* strbufs are meant to be used with all the usual C string and memory
16
* APIs. Given that the length of the buffer is known, it's often better to
17
+
* use the mem* functions than a str* one (e.g., memchr vs. strchr).
18
* Though, one has to be careful about the fact that str* functions often
19
* stop on NULs and that strbufs may have embedded NULs.
20
*
···
24
* strbufs have some invariants that are very important to keep in mind:
25
*
26
* - The `buf` member is never NULL, so it can be used in any usual C
27
+
* string operations safely. strbufs _have_ to be initialized either by
28
* `strbuf_init()` or by `= STRBUF_INIT` before the invariants, though.
29
*
30
* Do *not* assume anything on what `buf` really is (e.g. if it is
···
37
*
38
* - The `buf` member is a byte array that has at least `len + 1` bytes
39
* allocated. The extra byte is used to store a `'\0'`, allowing the
40
+
* `buf` member to be a valid C-string. All strbuf functions ensure this
41
* invariant is preserved.
42
*
43
* NOTE: It is OK to "play" with the buffer directly if you work it this
+15
-16
t/README
+15
-16
t/README
···
262
substrings or globs or individual test numbers or ranges with an
263
optional negation prefix (of '!') that define what tests in a test
264
suite to include (or exclude, if negated) in the run. A range is two
265
-
numbers separated with a dash and matches a range of tests with both
266
-
ends been included. You may omit the first or the second number to
267
mean "from the first test" or "up to the very last test" respectively.
268
269
The argument to --run is split on commas into separate strings,
···
274
on all tests that match either the glob *rebase* or the glob
275
*merge?cherry-pick*.
276
277
-
If --run starts with an unprefixed number or range the initial
278
-
set of tests to run is empty. If the first item starts with '!'
279
all the tests are added to the initial set. After initial set is
280
-
determined every test number or range is added or excluded from
281
the set one by one, from left to right.
282
283
For example, to run only tests up to a specific test (21), one
···
579
580
Recommended style
581
-----------------
582
-
Here are some recommented styles when writing test case.
583
584
-
- Keep test title the same line with test helper function itself.
585
586
-
Take test_expect_success helper for example, write it like:
587
588
test_expect_success 'test title' '
589
... test body ...
···
595
'test title' \
596
'... test body ...'
597
598
599
-
- End the line with a single quote.
600
-
601
-
- Indent the body of here-document, and use "<<-" instead of "<<"
602
to strip leading TABs used for indentation:
603
604
test_expect_success 'test something' '
···
624
'
625
626
- Quote or escape the EOF delimiter that begins a here-document if
627
-
there is no parameter and other expansion in it, to signal readers
628
that they can skim it more casually:
629
630
cmd <<-\EOF
···
638
Here are a few examples of things you probably should and shouldn't do
639
when writing tests.
640
641
-
Here are the "do's:"
642
643
- Put all code inside test_expect_success and other assertions.
644
···
1237
because the things the very basic core test tries to achieve is
1238
to serve as a basis for people who are changing the Git internals
1239
drastically. For these people, after making certain changes,
1240
-
not seeing failures from the basic test _is_ a failure. And
1241
-
such drastic changes to the core Git that even changes these
1242
otherwise supposedly stable object IDs should be accompanied by
1243
an update to t0000-basic.sh.
1244
···
1248
hardcoded the object IDs like t0000-basic.sh does, that defeats
1249
the purpose of t0000-basic.sh, which is to isolate that level of
1250
validation in one place. Your test also ends up needing
1251
-
updating when such a change to the internal happens, so do _not_
1252
do it and leave the low level of validation to t0000-basic.sh.
1253
1254
Test coverage
···
262
substrings or globs or individual test numbers or ranges with an
263
optional negation prefix (of '!') that define what tests in a test
264
suite to include (or exclude, if negated) in the run. A range is two
265
+
numbers separated with a dash and specifies an inclusive range of tests
266
+
to run. You may omit the first or the second number to
267
mean "from the first test" or "up to the very last test" respectively.
268
269
The argument to --run is split on commas into separate strings,
···
274
on all tests that match either the glob *rebase* or the glob
275
*merge?cherry-pick*.
276
277
+
If --run starts with an unprefixed number or range, the initial
278
+
set of tests to run is empty. If the first item starts with '!',
279
all the tests are added to the initial set. After initial set is
280
+
determined, every test number or range is added or excluded from
281
the set one by one, from left to right.
282
283
For example, to run only tests up to a specific test (21), one
···
579
580
Recommended style
581
-----------------
582
583
+
- Keep the test_expect_* function call and test title on
584
+
the same line.
585
586
+
For example, with test_expect_success, write it like:
587
588
test_expect_success 'test title' '
589
... test body ...
···
595
'test title' \
596
'... test body ...'
597
598
+
- End the line with an opening single quote.
599
600
+
- Indent here-document bodies, and use "<<-" instead of "<<"
601
to strip leading TABs used for indentation:
602
603
test_expect_success 'test something' '
···
623
'
624
625
- Quote or escape the EOF delimiter that begins a here-document if
626
+
there is no parameter or other expansion in it, to signal readers
627
that they can skim it more casually:
628
629
cmd <<-\EOF
···
637
Here are a few examples of things you probably should and shouldn't do
638
when writing tests.
639
640
+
The "do's:"
641
642
- Put all code inside test_expect_success and other assertions.
643
···
1236
because the things the very basic core test tries to achieve is
1237
to serve as a basis for people who are changing the Git internals
1238
drastically. For these people, after making certain changes,
1239
+
not seeing failures from the basic test _is_ a failure. Any
1240
+
Git core changes so drastic that they change even these
1241
otherwise supposedly stable object IDs should be accompanied by
1242
an update to t0000-basic.sh.
1243
···
1247
hardcoded the object IDs like t0000-basic.sh does, that defeats
1248
the purpose of t0000-basic.sh, which is to isolate that level of
1249
validation in one place. Your test also ends up needing
1250
+
an update whenever the internals change, so do _not_
1251
do it and leave the low level of validation to t0000-basic.sh.
1252
1253
Test coverage