Fossil SCM
Fixed a number of "the the" duplications in comments, documentation, and HTML (templates). Left the 17 occurences of same in sqlite.c alone.
Commit
b00e462ffc38a10d88f6e381b4a645ddbe0037a1
Parent
b1cc5a4c12a6542…
5 files changed
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
| --- autosetup/system.tcl | ||
| +++ autosetup/system.tcl | ||
| @@ -104,11 +104,11 @@ | ||
| 104 | 104 | # |
| 105 | 105 | # Reads the input file <srcdir>/$template and writes the output file $outfile. |
| 106 | 106 | # If $outfile is blank/omitted, $template should end with ".in" which |
| 107 | 107 | # is removed to create the output file name. |
| 108 | 108 | # |
| 109 | -# Each pattern of the form @define@ is replaced the the corresponding | |
| 109 | +# Each pattern of the form @define@ is replaced by the corresponding | |
| 110 | 110 | # define, if it exists, or left unchanged if not. |
| 111 | 111 | # |
| 112 | 112 | # The special value @srcdir@ is subsituted with the relative |
| 113 | 113 | # path to the source directory from the directory where the output |
| 114 | 114 | # file is created. Use @top_srcdir@ for the absolute path. |
| 115 | 115 |
| --- autosetup/system.tcl | |
| +++ autosetup/system.tcl | |
| @@ -104,11 +104,11 @@ | |
| 104 | # |
| 105 | # Reads the input file <srcdir>/$template and writes the output file $outfile. |
| 106 | # If $outfile is blank/omitted, $template should end with ".in" which |
| 107 | # is removed to create the output file name. |
| 108 | # |
| 109 | # Each pattern of the form @define@ is replaced the the corresponding |
| 110 | # define, if it exists, or left unchanged if not. |
| 111 | # |
| 112 | # The special value @srcdir@ is subsituted with the relative |
| 113 | # path to the source directory from the directory where the output |
| 114 | # file is created. Use @top_srcdir@ for the absolute path. |
| 115 |
| --- autosetup/system.tcl | |
| +++ autosetup/system.tcl | |
| @@ -104,11 +104,11 @@ | |
| 104 | # |
| 105 | # Reads the input file <srcdir>/$template and writes the output file $outfile. |
| 106 | # If $outfile is blank/omitted, $template should end with ".in" which |
| 107 | # is removed to create the output file name. |
| 108 | # |
| 109 | # Each pattern of the form @define@ is replaced by the corresponding |
| 110 | # define, if it exists, or left unchanged if not. |
| 111 | # |
| 112 | # The special value @srcdir@ is subsituted with the relative |
| 113 | # path to the source directory from the directory where the output |
| 114 | # file is created. Use @top_srcdir@ for the absolute path. |
| 115 |
+1
-1
| --- src/tktsetup.c | ||
| +++ src/tktsetup.c | ||
| @@ -662,11 +662,11 @@ | ||
| 662 | 662 | ** WEBPAGE: tktsetup_rpttplt |
| 663 | 663 | */ |
| 664 | 664 | void tktsetup_rpttplt_page(void){ |
| 665 | 665 | static const char zDesc[] = |
| 666 | 666 | @ Enter the default ticket report format template. This is the |
| 667 | - @ the template report format that initially appears when creating a | |
| 667 | + @ template report format that initially appears when creating a | |
| 668 | 668 | @ new ticket summary report. |
| 669 | 669 | ; |
| 670 | 670 | tktsetup_generic( |
| 671 | 671 | "Default Report Template", |
| 672 | 672 | "ticket-report-template", |
| 673 | 673 |
| --- src/tktsetup.c | |
| +++ src/tktsetup.c | |
| @@ -662,11 +662,11 @@ | |
| 662 | ** WEBPAGE: tktsetup_rpttplt |
| 663 | */ |
| 664 | void tktsetup_rpttplt_page(void){ |
| 665 | static const char zDesc[] = |
| 666 | @ Enter the default ticket report format template. This is the |
| 667 | @ the template report format that initially appears when creating a |
| 668 | @ new ticket summary report. |
| 669 | ; |
| 670 | tktsetup_generic( |
| 671 | "Default Report Template", |
| 672 | "ticket-report-template", |
| 673 |
| --- src/tktsetup.c | |
| +++ src/tktsetup.c | |
| @@ -662,11 +662,11 @@ | |
| 662 | ** WEBPAGE: tktsetup_rpttplt |
| 663 | */ |
| 664 | void tktsetup_rpttplt_page(void){ |
| 665 | static const char zDesc[] = |
| 666 | @ Enter the default ticket report format template. This is the |
| 667 | @ template report format that initially appears when creating a |
| 668 | @ new ticket summary report. |
| 669 | ; |
| 670 | tktsetup_generic( |
| 671 | "Default Report Template", |
| 672 | "ticket-report-template", |
| 673 |
+1
-1
| --- test/release-checklist.wiki | ||
| +++ test/release-checklist.wiki | ||
| @@ -37,11 +37,11 @@ | ||
| 37 | 37 | <li> Windows (vc++) |
| 38 | 38 | <li> OpenBSD |
| 39 | 39 | </ol> |
| 40 | 40 | |
| 41 | 41 | <li><p> |
| 42 | -Run at least one occurrence of the the following commands on every | |
| 42 | +Run at least one occurrence of the following commands on every | |
| 43 | 43 | platform: |
| 44 | 44 | <ol type="a"> |
| 45 | 45 | <li> <b>fossil rebuild</b> |
| 46 | 46 | <li> <b>fossil sync</b> |
| 47 | 47 | <li> <b>fossil test-integrity</b> |
| 48 | 48 |
| --- test/release-checklist.wiki | |
| +++ test/release-checklist.wiki | |
| @@ -37,11 +37,11 @@ | |
| 37 | <li> Windows (vc++) |
| 38 | <li> OpenBSD |
| 39 | </ol> |
| 40 | |
| 41 | <li><p> |
| 42 | Run at least one occurrence of the the following commands on every |
| 43 | platform: |
| 44 | <ol type="a"> |
| 45 | <li> <b>fossil rebuild</b> |
| 46 | <li> <b>fossil sync</b> |
| 47 | <li> <b>fossil test-integrity</b> |
| 48 |
| --- test/release-checklist.wiki | |
| +++ test/release-checklist.wiki | |
| @@ -37,11 +37,11 @@ | |
| 37 | <li> Windows (vc++) |
| 38 | <li> OpenBSD |
| 39 | </ol> |
| 40 | |
| 41 | <li><p> |
| 42 | Run at least one occurrence of the following commands on every |
| 43 | platform: |
| 44 | <ol type="a"> |
| 45 | <li> <b>fossil rebuild</b> |
| 46 | <li> <b>fossil sync</b> |
| 47 | <li> <b>fossil test-integrity</b> |
| 48 |
+1
-1
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -176,11 +176,11 @@ | ||
| 176 | 176 | A manifest has zero or more Q-cards. A Q-card is similar to a P-card |
| 177 | 177 | in that it defines a predecessor to the current check-in. But |
| 178 | 178 | whereas a P-card defines the immediate ancestor or a merge |
| 179 | 179 | ancestor, the Q-card is used to identify a single check-in or a small |
| 180 | 180 | range of check-ins which were cherry-picked for inclusion in or |
| 181 | -exclusion from the the current manifest. The first argument of | |
| 181 | +exclusion from the current manifest. The first argument of | |
| 182 | 182 | the Q-card is the artifact ID of another manifest (the "target") |
| 183 | 183 | which has had its changes included or excluded in the current manifest. |
| 184 | 184 | The target is preceeded by "+" or "-" to show inclusion or |
| 185 | 185 | exclusion, respectively. The optional second argument to the |
| 186 | 186 | Q-card is another manifest artifact ID which is the "baseline" |
| 187 | 187 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -176,11 +176,11 @@ | |
| 176 | A manifest has zero or more Q-cards. A Q-card is similar to a P-card |
| 177 | in that it defines a predecessor to the current check-in. But |
| 178 | whereas a P-card defines the immediate ancestor or a merge |
| 179 | ancestor, the Q-card is used to identify a single check-in or a small |
| 180 | range of check-ins which were cherry-picked for inclusion in or |
| 181 | exclusion from the the current manifest. The first argument of |
| 182 | the Q-card is the artifact ID of another manifest (the "target") |
| 183 | which has had its changes included or excluded in the current manifest. |
| 184 | The target is preceeded by "+" or "-" to show inclusion or |
| 185 | exclusion, respectively. The optional second argument to the |
| 186 | Q-card is another manifest artifact ID which is the "baseline" |
| 187 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -176,11 +176,11 @@ | |
| 176 | A manifest has zero or more Q-cards. A Q-card is similar to a P-card |
| 177 | in that it defines a predecessor to the current check-in. But |
| 178 | whereas a P-card defines the immediate ancestor or a merge |
| 179 | ancestor, the Q-card is used to identify a single check-in or a small |
| 180 | range of check-ins which were cherry-picked for inclusion in or |
| 181 | exclusion from the current manifest. The first argument of |
| 182 | the Q-card is the artifact ID of another manifest (the "target") |
| 183 | which has had its changes included or excluded in the current manifest. |
| 184 | The target is preceeded by "+" or "-" to show inclusion or |
| 185 | exclusion, respectively. The optional second argument to the |
| 186 | Q-card is another manifest artifact ID which is the "baseline" |
| 187 |
+1
-1
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -90,11 +90,11 @@ | ||
| 90 | 90 | Linus Torvalds at the root. Individual developers each have their own |
| 91 | 91 | private branches of the source tree into which they make their own changes. |
| 92 | 92 | They then encourage first-tier integrators to pull those changes. The |
| 93 | 93 | first-tier integrators merge together changes from multiple contributors |
| 94 | 94 | then try to get second-tier integrators to pull their branches. The |
| 95 | -changes merge up the the hierarchy until (hopefully) they are pulled into | |
| 95 | +changes merge up the hierarchy until (hopefully) they are pulled into | |
| 96 | 96 | "Linus's branch", at which time they become part of the "official" Linux. |
| 97 | 97 | |
| 98 | 98 | In Git, each branch is "owned" by the person who creates it and works |
| 99 | 99 | on it. The owner might pull changes from others, but the owner is always |
| 100 | 100 | in control of the branch. Branches are developer-centric. |
| 101 | 101 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -90,11 +90,11 @@ | |
| 90 | Linus Torvalds at the root. Individual developers each have their own |
| 91 | private branches of the source tree into which they make their own changes. |
| 92 | They then encourage first-tier integrators to pull those changes. The |
| 93 | first-tier integrators merge together changes from multiple contributors |
| 94 | then try to get second-tier integrators to pull their branches. The |
| 95 | changes merge up the the hierarchy until (hopefully) they are pulled into |
| 96 | "Linus's branch", at which time they become part of the "official" Linux. |
| 97 | |
| 98 | In Git, each branch is "owned" by the person who creates it and works |
| 99 | on it. The owner might pull changes from others, but the owner is always |
| 100 | in control of the branch. Branches are developer-centric. |
| 101 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -90,11 +90,11 @@ | |
| 90 | Linus Torvalds at the root. Individual developers each have their own |
| 91 | private branches of the source tree into which they make their own changes. |
| 92 | They then encourage first-tier integrators to pull those changes. The |
| 93 | first-tier integrators merge together changes from multiple contributors |
| 94 | then try to get second-tier integrators to pull their branches. The |
| 95 | changes merge up the hierarchy until (hopefully) they are pulled into |
| 96 | "Linus's branch", at which time they become part of the "official" Linux. |
| 97 | |
| 98 | In Git, each branch is "owned" by the person who creates it and works |
| 99 | on it. The owner might pull changes from others, but the owner is always |
| 100 | in control of the branch. Branches are developer-centric. |
| 101 |