+5 -5

Documentation/SubmittingPatches

··· 393 393 394 394 Learn to use format-patch and send-email if possible. These commands 395 395 are optimized for the workflow of sending patches, avoiding many ways 396 396 - your existing e-mail client that is optimized for "multipart/*" mime 397 397 - type e-mails to corrupt and render your patches unusable. 396 396 + your existing e-mail client (often optimized for "multipart/*" MIME 397 397 + type e-mails) might render your patches unusable. 398 398 399 399 People on the Git mailing list need to be able to read and 400 400 comment on the changes you are submitting. It is important for ··· 515 515 516 516 git://git.ozlabs.org/~paulus/gitk 517 517 518 518 - Those who are interested in improve gitk can volunteer to help Paul 519 519 - in maintaining it cf. <YntxL/fTplFm8lr6@cleo>. 518 518 + Those who are interested in improving gitk can volunteer to help Paul 519 519 + maintain it, cf. <YntxL/fTplFm8lr6@cleo>. 520 520 521 521 - `po/` comes from the localization coordinator, Jiang Xin: 522 522 ··· 556 556 557 557 In any time between the (2)-(3) cycle, the maintainer may pick it up 558 558 from the list and queue it to `seen`, in order to make it easier for 559 559 - people play with it without having to pick up and apply the patch to 559 559 + people to play with it without having to pick up and apply the patch to 560 560 their trees themselves. 561 561 562 562 [[patch-status]]

+1 -1

Documentation/config/transfer.txt

··· 21 21 system. 22 22 * The git programs will pass the full URL to one another as arguments 23 23 on the command-line, meaning the credentials will be exposed to other 24 24 - users on OS's or systems that allow other users to see the full 24 24 + unprivileged users on systems that allow them to see the full 25 25 process list of other users. On linux the "hidepid" setting 26 26 documented in procfs(5) allows for configuring this behavior. 27 27 +

+1 -1

Documentation/diff-options.txt

··· 301 301 302 302 -z:: 303 303 ifdef::git-log[] 304 304 - Separate the commits with NULs instead of with new newlines. 304 304 + Separate the commits with NULs instead of newlines. 305 305 + 306 306 Also, when `--raw` or `--numstat` has been given, do not munge 307 307 pathnames and use NULs as output field terminators.

+1 -1

Documentation/git-branch.txt

··· 324 324 multiple times, in which case the last key becomes the primary 325 325 key. The keys supported are the same as those in `git 326 326 for-each-ref`. Sort order defaults to the value configured for the 327 327 - `branch.sort` variable if exists, or to sorting based on the 327 327 + `branch.sort` variable if it exists, or to sorting based on the 328 328 full refname (including `refs/...` prefix). This lists 329 329 detached HEAD (if present) first, then local branches and 330 330 finally remote-tracking branches. See linkgit:git-config[1].

+1 -1

Documentation/git-range-diff.txt

··· 166 166 167 167 In this example, there are 3 old and 3 new commits, where the developer 168 168 removed the 3rd, added a new one before the first two, and modified the 169 169 - commit message of the 2nd commit as well its diff. 169 169 + commit message of the 2nd commit as well as its diff. 170 170 171 171 When the output goes to a terminal, it is color-coded by default, just 172 172 like regular `git diff`'s output. In addition, the first line (adding a

+3 -3

Documentation/git.txt

··· 96 96 to avoid ambiguity with `<name>` containing one. 97 97 + 98 98 This is useful for cases where you want to pass transitory 99 99 - configuration options to git, but are doing so on OS's where 100 100 - other processes might be able to read your cmdline 101 101 - (e.g. `/proc/self/cmdline`), but not your environ 99 99 + configuration options to git, but are doing so on operating systems 100 100 + where other processes might be able to read your command line 101 101 + (e.g. `/proc/self/cmdline`), but not your environment 102 102 (e.g. `/proc/self/environ`). That behavior is the default on 103 103 Linux, but may not be on your system. 104 104 +

+2 -2

Documentation/gitattributes.txt

··· 1151 1151 ^^^^^^^^^^^^^^^^^^^^^^ 1152 1152 1153 1153 This attribute controls the length of conflict markers left in 1154 1154 - the work tree file during a conflicted merge. Only setting to 1155 1155 - the value to a positive integer has any meaningful effect. 1154 1154 + the work tree file during a conflicted merge. Only a positive 1155 1155 + integer has a meaningful effect. 1156 1156 1157 1157 For example, this line in `.gitattributes` can be used to tell the merge 1158 1158 machinery to leave much longer (instead of the usual 7-character-long)

+1 -1

Documentation/giteveryday.txt

··· 229 229 git am -3 -k` 230 230 231 231 An alternate participant submission mechanism is using the 232 232 - `git request-pull` or pull-request mechanisms (e.g as used on 232 232 + `git request-pull` or pull-request mechanisms (e.g. as used on 233 233 GitHub (www.github.com) to notify your upstream of your 234 234 contribution. 235 235

+2 -2

contrib/README

··· 23 23 lesser degree various foreign SCM interfaces, so you know the 24 24 drill. 25 25 26 26 - I expect that things that start their life in the contrib/ area 26 26 + I expect things that start their life in the contrib/ area 27 27 to graduate out of contrib/ once they mature, either by becoming 28 28 projects on their own, or moving to the toplevel directory. On 29 29 the other hand, I expect I'll be proposing removal of disused ··· 31 31 32 32 If you have new things to add to this area, please first propose 33 33 it on the git mailing list, and after a list discussion proves 34 34 - there are some general interests (it does not have to be a 34 34 + there is general interest (it does not have to be a 35 35 list-wide consensus for a tool targeted to a relatively narrow 36 36 audience -- for example I do not work with projects whose 37 37 upstream is svn, so I have no use for git-svn myself, but it is

+1 -1

fsmonitor--daemon.h

··· 99 99 * to only mean an external GITDIR referenced by a ".git" file. 100 100 * 101 101 * The platform FS event backends will receive watch-specific 102 102 - * relative paths (except for those OS's that always emit absolute 102 102 + * relative paths (except for those OSes that always emit absolute 103 103 * paths). We use the following enum and routines to classify each 104 104 * path so that we know how to handle it. There is a slight asymmetry 105 105 * here because ".git/" is inside the working directory and the

+4 -4

strbuf.h

··· 12 12 struct string_list; 13 13 14 14 /** 15 15 - * strbuf's are meant to be used with all the usual C string and memory 15 15 + * strbufs are meant to be used with all the usual C string and memory 16 16 * APIs. Given that the length of the buffer is known, it's often better to 17 17 - * use the mem* functions than a str* one (memchr vs. strchr e.g.). 17 17 + * use the mem* functions than a str* one (e.g., memchr vs. strchr). 18 18 * Though, one has to be careful about the fact that str* functions often 19 19 * stop on NULs and that strbufs may have embedded NULs. 20 20 * ··· 24 24 * strbufs have some invariants that are very important to keep in mind: 25 25 * 26 26 * - The `buf` member is never NULL, so it can be used in any usual C 27 27 - * string operations safely. strbuf's _have_ to be initialized either by 27 27 + * string operations safely. strbufs _have_ to be initialized either by 28 28 * `strbuf_init()` or by `= STRBUF_INIT` before the invariants, though. 29 29 * 30 30 * Do *not* assume anything on what `buf` really is (e.g. if it is ··· 37 37 * 38 38 * - The `buf` member is a byte array that has at least `len + 1` bytes 39 39 * allocated. The extra byte is used to store a `'\0'`, allowing the 40 40 - * `buf` member to be a valid C-string. Every strbuf function ensure this 40 40 + * `buf` member to be a valid C-string. All strbuf functions ensure this 41 41 * invariant is preserved. 42 42 * 43 43 * NOTE: It is OK to "play" with the buffer directly if you work it this

+15 -16

t/README

··· 262 262 substrings or globs or individual test numbers or ranges with an 263 263 optional negation prefix (of '!') that define what tests in a test 264 264 suite to include (or exclude, if negated) in the run. A range is two 265 265 - numbers separated with a dash and matches a range of tests with both 266 266 - ends been included. You may omit the first or the second number to 265 265 + numbers separated with a dash and specifies an inclusive range of tests 266 266 + to run. You may omit the first or the second number to 267 267 mean "from the first test" or "up to the very last test" respectively. 268 268 269 269 The argument to --run is split on commas into separate strings, ··· 274 274 on all tests that match either the glob *rebase* or the glob 275 275 *merge?cherry-pick*. 276 276 277 277 - If --run starts with an unprefixed number or range the initial 278 278 - set of tests to run is empty. If the first item starts with '!' 277 277 + If --run starts with an unprefixed number or range, the initial 278 278 + set of tests to run is empty. If the first item starts with '!', 279 279 all the tests are added to the initial set. After initial set is 280 280 - determined every test number or range is added or excluded from 280 280 + determined, every test number or range is added or excluded from 281 281 the set one by one, from left to right. 282 282 283 283 For example, to run only tests up to a specific test (21), one ··· 579 579 580 580 Recommended style 581 581 ----------------- 582 582 - Here are some recommented styles when writing test case. 583 582 584 584 - - Keep test title the same line with test helper function itself. 583 583 + - Keep the test_expect_* function call and test title on 584 584 + the same line. 585 585 586 586 - Take test_expect_success helper for example, write it like: 586 586 + For example, with test_expect_success, write it like: 587 587 588 588 test_expect_success 'test title' ' 589 589 ... test body ... ··· 595 595 'test title' \ 596 596 '... test body ...' 597 597 598 598 + - End the line with an opening single quote. 598 599 599 599 - - End the line with a single quote. 600 600 - 601 601 - - Indent the body of here-document, and use "<<-" instead of "<<" 600 600 + - Indent here-document bodies, and use "<<-" instead of "<<" 602 601 to strip leading TABs used for indentation: 603 602 604 603 test_expect_success 'test something' ' ··· 624 623 ' 625 624 626 625 - Quote or escape the EOF delimiter that begins a here-document if 627 627 - there is no parameter and other expansion in it, to signal readers 626 626 + there is no parameter or other expansion in it, to signal readers 628 627 that they can skim it more casually: 629 628 630 629 cmd <<-\EOF ··· 638 637 Here are a few examples of things you probably should and shouldn't do 639 638 when writing tests. 640 639 641 641 - Here are the "do's:" 640 640 + The "do's:" 642 641 643 642 - Put all code inside test_expect_success and other assertions. 644 643 ··· 1237 1236 because the things the very basic core test tries to achieve is 1238 1237 to serve as a basis for people who are changing the Git internals 1239 1238 drastically. For these people, after making certain changes, 1240 1240 - not seeing failures from the basic test _is_ a failure. And 1241 1241 - such drastic changes to the core Git that even changes these 1239 1239 + not seeing failures from the basic test _is_ a failure. Any 1240 1240 + Git core changes so drastic that they change even these 1242 1241 otherwise supposedly stable object IDs should be accompanied by 1243 1242 an update to t0000-basic.sh. 1244 1243 ··· 1248 1247 hardcoded the object IDs like t0000-basic.sh does, that defeats 1249 1248 the purpose of t0000-basic.sh, which is to isolate that level of 1250 1249 validation in one place. Your test also ends up needing 1251 1251 - updating when such a change to the internal happens, so do _not_ 1250 1250 + an update whenever the internals change, so do _not_ 1252 1251 do it and leave the low level of validation to t0000-basic.sh. 1253 1252 1254 1253 Test coverage