{"thread":{"id":"55436","subject":"[PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","startedAt":"2021-04-05T21:49:16Z","lastAt":"2021-06-13T17:13:34Z","messageCount":68,"participants":["Varun Varada","Michal Suchánek","Jeff King","Junio C Hamano","Felipe Contreras","Robert P. J. Day","Kerry, Richard","Robert Coup","Philip Oakley"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"421015","messageId":"CAD2i4DBj6fNvq=Lc3KiXJj5uBpteyKfEKp7ATOWrTE36KUeRww@mail.gmail.com","threadId":"55436","inReplyTo":null,"subject":"[PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-04-05T21:48:58Z","receivedAt":"2021-04-05T21:49:16Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"There are a bunch of places in the code/docs which use the word \"impact\"\nincorrectly. This is especially true of places where it says \"will not\nimpact\", which suggests that it might have an effect, albeit not as\nstrong of a one. This commit replaces all of these with their\nappropriate alternative so that the docs not only does not use jargon,\nbut are also unambiguous.\n\nSigned-off-by: Varun Varada \n---\n Documentation/MyFirstContribution.txt | 2 +-\n Documentation/MyFirstObjectWalk.txt | 2 +-\n Documentation/config/pack.txt | 2 +-\n Documentation/git-fast-import.txt | 14 +++++++-------\n Documentation/git-fetch.txt | 2 +-\n .../technical/hash-function-transition.txt | 2 +-\n Documentation/user-manual.txt | 4 ++--\n advice.c | 2 +-\n builtin/fast-import.c | 2 +-\n builtin/pack-objects.c | 2 +-\n compat/nedmalloc/malloc.c.h | 2 +-\n contrib/coccinelle/README | 2 +-\n dir.c | 2 +-\n t/perf/p5550-fetch-tags.sh | 2 +-\n t/t0008-ignores.sh | 2 +-\n t/t0303-credential-external.sh | 2 +-\n t/t2020-checkout-detach.sh | 4 ++--\n t/t4013-diff-various.sh | 2 +-\n t/t5000-tar-tree.sh | 2 +-\n t/test-lib-functions.sh | 2 +-\n 20 files changed, 28 insertions(+), 28 deletions(-)\n\ndiff --git a/Documentation/MyFirstContribution.txt\nb/Documentation/MyFirstContribution.txt\nindex af0a9da62e..8372a7e59e 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\nhow to show it in the general\n command list shown by `git help git` or `git help -a`, which is generated from\n `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n line above it in alphabetical order. Now, we can add some attributes about the\n-command which impacts where it shows up in the aforementioned help\ncommands. The\n+command which affects where it shows up in the aforementioned help\ncommands. The\n top of `command-list.txt` shares some information about what each attribute\n means; in those help pages, the commands are sorted according to these\n attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\ndiff --git a/Documentation/MyFirstObjectWalk.txt\nb/Documentation/MyFirstObjectWalk.txt\nindex 2d10eea7a9..fd5bb8fb7d 100644\n--- a/Documentation/MyFirstObjectWalk.txt\n+++ b/Documentation/MyFirstObjectWalk.txt\n@@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n By running your walk with and without the filter, you should find\nthat the total\n object count in each case is identical. You can also time each invocation of\n the `walken` subcommand, with and without `omitted` being passed in, to confirm\n-to yourself the runtime impact of tracking all omitted objects.\n+to yourself the runtime effect of tracking all omitted objects.\n\n === Changing the Order\n\ndiff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\nindex 3da4ea98e2..00fcc9d7c7 100644\n--- a/Documentation/config/pack.txt\n+++ b/Documentation/config/pack.txt\n@@ -55,7 +55,7 @@ pack.deltaCacheSize::\n This cache is used to speed up the writing object phase by not\n having to recompute the final delta result once the best match\n for all objects is found. Repacking large repositories on machines\n- which are tight with memory might be badly impacted by this though,\n+ which are tight with memory might be badly affected by this though,\n especially if this cache pushes the system into swapping.\n A value of 0 means no limit. The smallest size of 1 byte may be\n used to virtually disable this cache. Defaults to 256 MiB.\ndiff --git a/Documentation/git-fast-import.txt\nb/Documentation/git-fast-import.txt\nindex 39cfa05b28..c6d8e4e1d7 100644\n--- a/Documentation/git-fast-import.txt\n+++ b/Documentation/git-fast-import.txt\n@@ -58,7 +58,7 @@ OPTIONS\n allowing fast-import to access the filesystem outside of the\n repository). These options are disabled by default, but can be\n allowed by providing this option on the command line. This\n- currently impacts only the `export-marks`, `import-marks`, and\n+ currently affects only the `export-marks`, `import-marks`, and\n `import-marks-if-exists` feature commands.\n +\n Only enable this option if you trust the program generating the\n@@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n\n A `filecopy` command takes effect immediately. Once the source\n location has been copied to the destination any future commands\n-applied to the source location will not impact the destination of\n+applied to the source location will not affect the destination of\n the copy.\n\n `filerename`\n@@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n A `filerename` command takes effect immediately. Once the source\n location has been renamed to the destination any future commands\n applied to the source location will create new files there and not\n-impact the destination of the rename.\n+affect the destination of the rename.\n\n Note that a `filerename` is the same as a `filecopy` followed by a\n `filedelete` of the source location. There is a slight performance\n@@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\nto be required).\n ~~~~~~~~~~\n Causes fast-import to print the entire `progress` line unmodified to\n its standard output channel (file descriptor 1) when the command is\n-processed from the input stream. The command otherwise has no impact\n+processed from the input stream. The command otherwise has no effect\n on the current import, or on any of fast-import's internal state.\n\n ....\n@@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n ~~~~~~~~~~\n Causes fast-import to print the SHA-1 corresponding to a mark to\n stdout or to the file descriptor previously arranged with the\n-`--cat-blob-fd` argument. The command otherwise has no impact on the\n+`--cat-blob-fd` argument. The command otherwise has no effect on the\n current import; its purpose is to retrieve SHA-1s that later commits\n might want to refer to in their commit messages.\n\n@@ -1050,7 +1050,7 @@ this output safely.\n ~~~~~~~~~~\n Causes fast-import to print a blob to a file descriptor previously\n arranged with the `--cat-blob-fd` argument. The command otherwise\n-has no impact on the current import; its main purpose is to\n+has no effect on the current import; its main purpose is to\n retrieve blobs that may be in fast-import's memory but not\n accessible from the target repository.\n\n@@ -1366,7 +1366,7 @@ code considerably.\n\n The branch LRU builtin to fast-import tends to behave very well, and the\n cost of activating an inactive branch is so low that bouncing around\n-between branches has virtually no impact on import performance.\n+between branches has virtually no effect on import performance.\n\n Handling Renames\n ~~~~~~~~~~~~~~~~\ndiff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\nindex 9067c2079e..01cf3b3d16 100644\n--- a/Documentation/git-fetch.txt\n+++ b/Documentation/git-fetch.txt\n@@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n If left to accumulate, these stale references might make performance\n worse on big and busy repos that have a lot of branch churn, and\n e.g. make the output of commands like `git branch -a --contains\n-` needlessly verbose, as well as impacting anything else\n+` needlessly verbose, as well as affecting anything else\n that'll work with the complete set of known references.\n\n These remote-tracking references can be deleted as a one-off with\ndiff --git a/Documentation/technical/hash-function-transition.txt\nb/Documentation/technical/hash-function-transition.txt\nindex 7c1630bf83..f4296faffc 100644\n--- a/Documentation/technical/hash-function-transition.txt\n+++ b/Documentation/technical/hash-function-transition.txt\n@@ -42,7 +42,7 @@ mitigations.\n\n If SHA-1 and its variants were to be truly broken, Git's hash function\n could not be considered cryptographically secure any more. This would\n-impact the communication of hash values because we could not trust\n+affect the communication of hash values because we could not trust\n that a given hash value represented the known good version of content\n that the speaker intended.\n\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex fd480b8645..33c60c49d7 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n\n You are in 'detached HEAD' state. You can look around, make experimental\n changes and commit them, and you can discard any commits you make in this\n-state without impacting any branches by performing another switch.\n+state without affecting any branches by performing another switch.\n\n If you want to create a new branch to retain commits you create, you may\n do so (now or later) by using -c with the switch command again. Example:\n@@ -1189,7 +1189,7 @@ their histories forked. The work tree is\noverwritten by the result of\n the merge when this combining is done cleanly, or overwritten by a\n half-merged results when this combining results in conflicts.\n Therefore, if you have uncommitted changes touching the same files as\n-the ones impacted by the merge, Git will refuse to proceed. Most of\n+the ones affected by the merge, Git will refuse to proceed. Most of\n the time, you will want to commit your changes before you can merge,\n and if you don't, then linkgit:git-stash[1] can take these changes\n away while you're doing the merge, and reapply them afterwards.\ndiff --git a/advice.c b/advice.c\nindex 164742305f..9cbbb824a9 100644\n--- a/advice.c\n+++ b/advice.c\n@@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n \"\\n\"\n \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n \"changes and commit them, and you can discard any commits you make in this\\n\"\n- \"state without impacting any branches by switching back to a branch.\\n\"\n+ \"state without affecting any branches by switching back to a branch.\\n\"\n \"\\n\"\n \"If you want to create a new branch to retain commits you create, you may\\n\"\n \"do so (now or later) by using -c with the switch command. Example:\\n\"\ndiff --git a/builtin/fast-import.c b/builtin/fast-import.c\nindex 3afa81cf9a..24f362d2f4 100644\n--- a/builtin/fast-import.c\n+++ b/builtin/fast-import.c\n@@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\nconst char *prefix)\n * We don't parse most options until after we've seen the set of\n * \"feature\" lines at the start of the stream (which allows the command\n * line to override stream data). But we must do an early parse of any\n- * command-line options that impact how we interpret the feature lines.\n+ * command-line options that affect how we interpret the feature lines.\n */\n for (i = 1; i < argc; i++) {\n const char *arg = argv[i];\ndiff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\nindex 525c2d8552..749bbca241 100644\n--- a/builtin/pack-objects.c\n+++ b/builtin/pack-objects.c\n@@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n /*\n * Mark ourselves as active and see if the next step causes\n * us to cycle to another active object. It's important to do\n- * this _before_ we loop, because it impacts where we make the\n+ * this _before_ we loop, because it affects where we make the\n * cut, and thus how our total_depth counter works.\n * E.g., We may see a partial loop like:\n *\ndiff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h\nindex 814845d4b3..de13121d76 100644\n--- a/compat/nedmalloc/malloc.c.h\n+++ b/compat/nedmalloc/malloc.c.h\n@@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n #endif /* (FOOTERS && !INSECURE) */\n\n\n-/* In gcc, use __builtin_expect to minimize impact of checks */\n+/* In gcc, use __builtin_expect to minimize affect of checks */\n #if !INSECURE\n #if defined(__GNUC__) && __GNUC__ >= 3\n #define RTCHECK(e) __builtin_expect(e, 1)\ndiff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\nindex f0e80bd7f0..92979ec770 100644\n--- a/contrib/coccinelle/README\n+++ b/contrib/coccinelle/README\n@@ -40,4 +40,4 @@ There are two types of semantic patches:\n are ignored for checks, and can be applied using 'make coccicheck-pending'.\n\n This allows to expose plans of pending large scale refactorings without\n- impacting the bad pattern checks.\n+ affecting the bad pattern checks.\ndiff --git a/dir.c b/dir.c\nindex 3474e67e8f..235e26a90e 100644\n--- a/dir.c\n+++ b/dir.c\n@@ -2144,7 +2144,7 @@ static enum path_treatment\ntreat_path_fast(struct dir_struct *dir,\n /*\n * We get path_recurse in the first run when\n * directory_exists_in_index() returns index_nonexistent. We\n- * are sure that new changes in the index does not impact the\n+ * are sure that new changes in the index does not affect the\n * outcome. Return now.\n */\n return path_recurse;\ndiff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\nindex d0e0e019ea..1fcb98443c 100755\n--- a/t/perf/p5550-fetch-tags.sh\n+++ b/t/perf/p5550-fetch-tags.sh\n@@ -8,7 +8,7 @@ follows.\n\n The parent repository has a large number of tags which are disconnected from\n the rest of history. That makes them candidates for tag-following, but we never\n-actually grab them (and thus they will impact each subsequent fetch).\n+actually grab them (and thus they will affect each subsequent fetch).\n\n The child repository is a clone of parent, without the tags, and is at least\n one commit behind the parent (meaning that we will fetch one object and then\ndiff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\nindex a594b4aa7d..95daba4000 100755\n--- a/t/t0008-ignores.sh\n+++ b/t/t0008-ignores.sh\n@@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n # test standard ignores\n\n # First make sure that the presence of a file in the working tree\n-# does not impact results, but that the presence of a file in the\n+# does not affect results, but that the presence of a file in the\n # index does unless the --no-index option is used.\n\n for subdir in '' 'a/'\ndiff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\nindex f028fd1418..a9348f655a 100755\n--- a/t/t0303-credential-external.sh\n+++ b/t/t0303-credential-external.sh\n@@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n\n # clean before the test in case there is cruft left\n-# over from a previous run that would impact results\n+# over from a previous run that would affect results\n helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n\n helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\ndiff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\nindex bc46713a43..568c258c5a 100755\n--- a/t/t2020-checkout-detach.sh\n+++ b/t/t2020-checkout-detach.sh\n@@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\nno SHA-1 ellipsis when not as\n\n You are in 'detached HEAD' state. You can look around, make experimental\n changes and commit them, and you can discard any commits you make in this\n- state without impacting any branches by switching back to a branch.\n+ state without affecting any branches by switching back to a branch.\n\n If you want to create a new branch to retain commits you create, you may\n do so (now or later) by using -c with the switch command. Example:\n@@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\nprint SHA-1 ellipsis when asked\n\n You are in 'detached HEAD' state. You can look around, make experimental\n changes and commit them, and you can discard any commits you make in this\n- state without impacting any branches by switching back to a branch.\n+ state without affecting any branches by switching back to a branch.\n\n If you want to create a new branch to retain commits you create, you may\n do so (now or later) by using -c with the switch command. Example:\ndiff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\nindex 6cca8b84a6..97365a7786 100755\n--- a/t/t4013-diff-various.sh\n+++ b/t/t4013-diff-various.sh\n@@ -109,7 +109,7 @@ test_expect_success setup '\n git checkout -f master &&\n\n # Same merge as master, but with parents reversed. Hide it in a\n- # pseudo-ref to avoid impacting tests with --all.\n+ # pseudo-ref to avoid affecting tests with --all.\n commit=$(echo reverse |\n git commit-tree -p master^2 -p master^1 master^{tree}) &&\n git update-ref REVERSE $commit &&\ndiff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\nindex 7204799a0b..33a6efce2f 100755\n--- a/t/t5000-tar-tree.sh\n+++ b/t/t5000-tar-tree.sh\n@@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n # Pull the size and date of each entry in a tarfile using the system tar.\n #\n # We'll pull out only the year from the date; that avoids any question of\n-# timezones impacting the result (as long as we keep our test times away from a\n+# timezones affecting the result (as long as we keep our test times away from a\n # year boundary; our reference times are all in August).\n #\n # The output of tar_info is expected to be \" \", both in decimal. It\ndiff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\nindex 6348e8d733..ff65f86f50 100644\n--- a/t/test-lib-functions.sh\n+++ b/t/test-lib-functions.sh\n@@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n }\n\n # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n-# it also works for shell functions (though those functions cannot impact\n+# it also works for shell functions (though those functions cannot affect\n # the environment outside of the test_env invocation).\n test_env () {\n (\n-- \n2.17.1\n\n\nFrom varun Mon Apr 5 16:45:37 2021\nReturn-Path: \nReceived: (from varun@localhost)\nby black-diamond (8.15.2/8.15.2/Submit) id 135LjbIS027022;\nMon, 5 Apr 2021 16:45:37 -0500\nFrom: Varun Varada \nTo: git@vger.kernel.org\nCc: Varun Varada \nSubject: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"\nDate: Mon, 5 Apr 2021 16:44:35 -0500\nMessage-Id: <20210405214435.26979-1-varuncvarada@gmail.com>\nX-Mailer: git-send-email 2.17.1\n\nThere are a bunch of places in the code/docs which use the word \"impact\"\nincorrectly. This is especially true of places where it says \"will not\nimpact\", which suggests that it might have an effect, albeit not as\nstrong of a one. This commit replaces all of these with their\nappropriate alternative so that the docs not only does not use jargon,\nbut are also unambiguous.\n\nSigned-off-by: Varun Varada \n---\n Documentation/MyFirstContribution.txt | 2 +-\n Documentation/MyFirstObjectWalk.txt | 2 +-\n Documentation/config/pack.txt | 2 +-\n Documentation/git-fast-import.txt | 14 +++++++-------\n Documentation/git-fetch.txt | 2 +-\n .../technical/hash-function-transition.txt | 2 +-\n Documentation/user-manual.txt | 4 ++--\n advice.c | 2 +-\n builtin/fast-import.c | 2 +-\n builtin/pack-objects.c | 2 +-\n compat/nedmalloc/malloc.c.h | 2 +-\n contrib/coccinelle/README | 2 +-\n dir.c | 2 +-\n t/perf/p5550-fetch-tags.sh | 2 +-\n t/t0008-ignores.sh | 2 +-\n t/t0303-credential-external.sh | 2 +-\n t/t2020-checkout-detach.sh | 4 ++--\n t/t4013-diff-various.sh | 2 +-\n t/t5000-tar-tree.sh | 2 +-\n t/test-lib-functions.sh | 2 +-\n 20 files changed, 28 insertions(+), 28 deletions(-)\n\ndiff --git a/Documentation/MyFirstContribution.txt\nb/Documentation/MyFirstContribution.txt\nindex af0a9da62e..8372a7e59e 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\nhow to show it in the general\n command list shown by `git help git` or `git help -a`, which is generated from\n `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n line above it in alphabetical order. Now, we can add some attributes about the\n-command which impacts where it shows up in the aforementioned help\ncommands. The\n+command which affects where it shows up in the aforementioned help\ncommands. The\n top of `command-list.txt` shares some information about what each attribute\n means; in those help pages, the commands are sorted according to these\n attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\ndiff --git a/Documentation/MyFirstObjectWalk.txt\nb/Documentation/MyFirstObjectWalk.txt\nindex 2d10eea7a9..fd5bb8fb7d 100644\n--- a/Documentation/MyFirstObjectWalk.txt\n+++ b/Documentation/MyFirstObjectWalk.txt\n@@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n By running your walk with and without the filter, you should find\nthat the total\n object count in each case is identical. You can also time each invocation of\n the `walken` subcommand, with and without `omitted` being passed in, to confirm\n-to yourself the runtime impact of tracking all omitted objects.\n+to yourself the runtime effect of tracking all omitted objects.\n\n === Changing the Order\n\ndiff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\nindex 3da4ea98e2..00fcc9d7c7 100644\n--- a/Documentation/config/pack.txt\n+++ b/Documentation/config/pack.txt\n@@ -55,7 +55,7 @@ pack.deltaCacheSize::\n This cache is used to speed up the writing object phase by not\n having to recompute the final delta result once the best match\n for all objects is found. Repacking large repositories on machines\n- which are tight with memory might be badly impacted by this though,\n+ which are tight with memory might be badly affected by this though,\n especially if this cache pushes the system into swapping.\n A value of 0 means no limit. The smallest size of 1 byte may be\n used to virtually disable this cache. Defaults to 256 MiB.\ndiff --git a/Documentation/git-fast-import.txt\nb/Documentation/git-fast-import.txt\nindex 39cfa05b28..c6d8e4e1d7 100644\n--- a/Documentation/git-fast-import.txt\n+++ b/Documentation/git-fast-import.txt\n@@ -58,7 +58,7 @@ OPTIONS\n allowing fast-import to access the filesystem outside of the\n repository). These options are disabled by default, but can be\n allowed by providing this option on the command line. This\n- currently impacts only the `export-marks`, `import-marks`, and\n+ currently affects only the `export-marks`, `import-marks`, and\n `import-marks-if-exists` feature commands.\n +\n Only enable this option if you trust the program generating the\n@@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n\n A `filecopy` command takes effect immediately. Once the source\n location has been copied to the destination any future commands\n-applied to the source location will not impact the destination of\n+applied to the source location will not affect the destination of\n the copy.\n\n `filerename`\n@@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n A `filerename` command takes effect immediately. Once the source\n location has been renamed to the destination any future commands\n applied to the source location will create new files there and not\n-impact the destination of the rename.\n+affect the destination of the rename.\n\n Note that a `filerename` is the same as a `filecopy` followed by a\n `filedelete` of the source location. There is a slight performance\n@@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\nto be required).\n ~~~~~~~~~~\n Causes fast-import to print the entire `progress` line unmodified to\n its standard output channel (file descriptor 1) when the command is\n-processed from the input stream. The command otherwise has no impact\n+processed from the input stream. The command otherwise has no effect\n on the current import, or on any of fast-import's internal state.\n\n ....\n@@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n ~~~~~~~~~~\n Causes fast-import to print the SHA-1 corresponding to a mark to\n stdout or to the file descriptor previously arranged with the\n-`--cat-blob-fd` argument. The command otherwise has no impact on the\n+`--cat-blob-fd` argument. The command otherwise has no effect on the\n current import; its purpose is to retrieve SHA-1s that later commits\n might want to refer to in their commit messages.\n\n@@ -1050,7 +1050,7 @@ this output safely.\n ~~~~~~~~~~\n Causes fast-import to print a blob to a file descriptor previously\n arranged with the `--cat-blob-fd` argument. The command otherwise\n-has no impact on the current import; its main purpose is to\n+has no effect on the current import; its main purpose is to\n retrieve blobs that may be in fast-import's memory but not\n accessible from the target repository.\n\n@@ -1366,7 +1366,7 @@ code considerably.\n\n The branch LRU builtin to fast-import tends to behave very well, and the\n cost of activating an inactive branch is so low that bouncing around\n-between branches has virtually no impact on import performance.\n+between branches has virtually no effect on import performance.\n\n Handling Renames\n ~~~~~~~~~~~~~~~~\ndiff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\nindex 9067c2079e..01cf3b3d16 100644\n--- a/Documentation/git-fetch.txt\n+++ b/Documentation/git-fetch.txt\n@@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n If left to accumulate, these stale references might make performance\n worse on big and busy repos that have a lot of branch churn, and\n e.g. make the output of commands like `git branch -a --contains\n-` needlessly verbose, as well as impacting anything else\n+` needlessly verbose, as well as affecting anything else\n that'll work with the complete set of known references.\n\n These remote-tracking references can be deleted as a one-off with\ndiff --git a/Documentation/technical/hash-function-transition.txt\nb/Documentation/technical/hash-function-transition.txt\nindex 7c1630bf83..f4296faffc 100644\n--- a/Documentation/technical/hash-function-transition.txt\n+++ b/Documentation/technical/hash-function-transition.txt\n@@ -42,7 +42,7 @@ mitigations.\n\n If SHA-1 and its variants were to be truly broken, Git's hash function\n could not be considered cryptographically secure any more. This would\n-impact the communication of hash values because we could not trust\n+affect the communication of hash values because we could not trust\n that a given hash value represented the known good version of content\n that the speaker intended.\n\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex fd480b8645..33c60c49d7 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n\n You are in 'detached HEAD' state. You can look around, make experimental\n changes and commit them, and you can discard any commits you make in this\n-state without impacting any branches by performing another switch.\n+state without affecting any branches by performing another switch.\n\n If you want to create a new branch to retain commits you create, you may\n do so (now or later) by using -c with the switch command again. Example:\n@@ -1189,7 +1189,7 @@ their histories forked. The work tree is\noverwritten by the result of\n the merge when this combining is done cleanly, or overwritten by a\n half-merged results when this combining results in conflicts.\n Therefore, if you have uncommitted changes touching the same files as\n-the ones impacted by the merge, Git will refuse to proceed. Most of\n+the ones affected by the merge, Git will refuse to proceed. Most of\n the time, you will want to commit your changes before you can merge,\n and if you don't, then linkgit:git-stash[1] can take these changes\n away while you're doing the merge, and reapply them afterwards.\ndiff --git a/advice.c b/advice.c\nindex 164742305f..9cbbb824a9 100644\n--- a/advice.c\n+++ b/advice.c\n@@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n \"\\n\"\n \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n \"changes and commit them, and you can discard any commits you make in this\\n\"\n- \"state without impacting any branches by switching back to a branch.\\n\"\n+ \"state without affecting any branches by switching back to a branch.\\n\"\n \"\\n\"\n \"If you want to create a new branch to retain commits you create, you may\\n\"\n \"do so (now or later) by using -c with the switch command. Example:\\n\"\ndiff --git a/builtin/fast-import.c b/builtin/fast-import.c\nindex 3afa81cf9a..24f362d2f4 100644\n--- a/builtin/fast-import.c\n+++ b/builtin/fast-import.c\n@@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\nconst char *prefix)\n * We don't parse most options until after we've seen the set of\n * \"feature\" lines at the start of the stream (which allows the command\n * line to override stream data). But we must do an early parse of any\n- * command-line options that impact how we interpret the feature lines.\n+ * command-line options that affect how we interpret the feature lines.\n */\n for (i = 1; i < argc; i++) {\n const char *arg = argv[i];\ndiff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\nindex 525c2d8552..749bbca241 100644\n--- a/builtin/pack-objects.c\n+++ b/builtin/pack-objects.c\n@@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n /*\n * Mark ourselves as active and see if the next step causes\n * us to cycle to another active object. It's important to do\n- * this _before_ we loop, because it impacts where we make the\n+ * this _before_ we loop, because it affects where we make the\n * cut, and thus how our total_depth counter works.\n * E.g., We may see a partial loop like:\n *\ndiff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h\nindex 814845d4b3..de13121d76 100644\n--- a/compat/nedmalloc/malloc.c.h\n+++ b/compat/nedmalloc/malloc.c.h\n@@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n #endif /* (FOOTERS && !INSECURE) */\n\n\n-/* In gcc, use __builtin_expect to minimize impact of checks */\n+/* In gcc, use __builtin_expect to minimize affect of checks */\n #if !INSECURE\n #if defined(__GNUC__) && __GNUC__ >= 3\n #define RTCHECK(e) __builtin_expect(e, 1)\ndiff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\nindex f0e80bd7f0..92979ec770 100644\n--- a/contrib/coccinelle/README\n+++ b/contrib/coccinelle/README\n@@ -40,4 +40,4 @@ There are two types of semantic patches:\n are ignored for checks, and can be applied using 'make coccicheck-pending'.\n\n This allows to expose plans of pending large scale refactorings without\n- impacting the bad pattern checks.\n+ affecting the bad pattern checks.\ndiff --git a/dir.c b/dir.c\nindex 3474e67e8f..235e26a90e 100644\n--- a/dir.c\n+++ b/dir.c\n@@ -2144,7 +2144,7 @@ static enum path_treatment\ntreat_path_fast(struct dir_struct *dir,\n /*\n * We get path_recurse in the first run when\n * directory_exists_in_index() returns index_nonexistent. We\n- * are sure that new changes in the index does not impact the\n+ * are sure that new changes in the index does not affect the\n * outcome. Return now.\n */\n return path_recurse;\ndiff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\nindex d0e0e019ea..1fcb98443c 100755\n--- a/t/perf/p5550-fetch-tags.sh\n+++ b/t/perf/p5550-fetch-tags.sh\n@@ -8,7 +8,7 @@ follows.\n\n The parent repository has a large number of tags which are disconnected from\n the rest of history. That makes them candidates for tag-following, but we never\n-actually grab them (and thus they will impact each subsequent fetch).\n+actually grab them (and thus they will affect each subsequent fetch).\n\n The child repository is a clone of parent, without the tags, and is at least\n one commit behind the parent (meaning that we will fetch one object and then\ndiff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\nindex a594b4aa7d..95daba4000 100755\n--- a/t/t0008-ignores.sh\n+++ b/t/t0008-ignores.sh\n@@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n # test standard ignores\n\n # First make sure that the presence of a file in the working tree\n-# does not impact results, but that the presence of a file in the\n+# does not affect results, but that the presence of a file in the\n # index does unless the --no-index option is used.\n\n for subdir in '' 'a/'\ndiff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\nindex f028fd1418..a9348f655a 100755\n--- a/t/t0303-credential-external.sh\n+++ b/t/t0303-credential-external.sh\n@@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n\n # clean before the test in case there is cruft left\n-# over from a previous run that would impact results\n+# over from a previous run that would affect results\n helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n\n helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\ndiff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\nindex bc46713a43..568c258c5a 100755\n--- a/t/t2020-checkout-detach.sh\n+++ b/t/t2020-checkout-detach.sh\n@@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\nno SHA-1 ellipsis when not as\n\n You are in 'detached HEAD' state. You can look around, make experimental\n changes and commit them, and you can discard any commits you make in this\n- state without impacting any branches by switching back to a branch.\n+ state without affecting any branches by switching back to a branch.\n\n If you want to create a new branch to retain commits you create, you may\n do so (now or later) by using -c with the switch command. Example:\n@@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\nprint SHA-1 ellipsis when asked\n\n You are in 'detached HEAD' state. You can look around, make experimental\n changes and commit them, and you can discard any commits you make in this\n- state without impacting any branches by switching back to a branch.\n+ state without affecting any branches by switching back to a branch.\n\n If you want to create a new branch to retain commits you create, you may\n do so (now or later) by using -c with the switch command. Example:\ndiff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\nindex 6cca8b84a6..97365a7786 100755\n--- a/t/t4013-diff-various.sh\n+++ b/t/t4013-diff-various.sh\n@@ -109,7 +109,7 @@ test_expect_success setup '\n git checkout -f master &&\n\n # Same merge as master, but with parents reversed. Hide it in a\n- # pseudo-ref to avoid impacting tests with --all.\n+ # pseudo-ref to avoid affecting tests with --all.\n commit=$(echo reverse |\n git commit-tree -p master^2 -p master^1 master^{tree}) &&\n git update-ref REVERSE $commit &&\ndiff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\nindex 7204799a0b..33a6efce2f 100755\n--- a/t/t5000-tar-tree.sh\n+++ b/t/t5000-tar-tree.sh\n@@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n # Pull the size and date of each entry in a tarfile using the system tar.\n #\n # We'll pull out only the year from the date; that avoids any question of\n-# timezones impacting the result (as long as we keep our test times away from a\n+# timezones affecting the result (as long as we keep our test times away from a\n # year boundary; our reference times are all in August).\n #\n # The output of tar_info is expected to be \" \", both in decimal. It\ndiff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\nindex 6348e8d733..ff65f86f50 100644\n--- a/t/test-lib-functions.sh\n+++ b/t/test-lib-functions.sh\n@@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n }\n\n # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n-# it also works for shell functions (though those functions cannot impact\n+# it also works for shell functions (though those functions cannot affect\n # the environment outside of the test_env invocation).\n test_env () {\n (\n-- \n2.17.1\n"},{"id":"421049","messageId":"20210406092440.GZ6564@kitsune.suse.cz","threadId":"55436","inReplyTo":"CAD2i4DBj6fNvq=Lc3KiXJj5uBpteyKfEKp7ATOWrTE36KUeRww@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-04-06T09:24:40Z","receivedAt":"2021-04-06T09:24:45Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Mon, Apr 05, 2021 at 04:48:58PM -0500, Varun Varada wrote:\n> There are a bunch of places in the code/docs which use the word \"impact\"\n> incorrectly. This is especially true of places where it says \"will not\n> impact\", which suggests that it might have an effect, albeit not as\n> strong of a one. This commit replaces all of these with their\n> appropriate alternative so that the docs not only does not use jargon,\n> but are also unambiguous.\n\nHello,\n\nwhile using \"will not impact\" in an incorrect or unclear way may be a\nproblem the word \"impact\" in itself is not \"jargon\".\n\nFrom The Collaborative International Dictionary of English v.0.48 :\n\n Impact \\Im*pact\"\\, v. t. [imp. & p. p. Impacted; p. pr. & vb.\n n. Impacting.] [L. impactus, p. p. of impingere to push,\n strike against. See Impinge.]\n 1. To drive close; to press firmly together: to wedge into a\n place. --Woodward.\n [1913 Webster]\n \n 2. To affect or influence, especially in a significant or\n undesirable manner; as, budget cuts impacted the entire\n research program; the fish populations were adversely\n impacted by pollution.\n [PJC]\n \n 3. To collide forcefully with; to strike.\n [PJC]\n\nFrom WordNet (r) 3.0 (2006) :\n\n impact\n n 1: the striking of one body against another\n 2: a forceful consequence; a strong effect; \"the book had an\n important impact on my thinking\"; \"the book packs a wallop\"\n [syn: impact, wallop]\n 3: influencing strongly; \"they resented the impingement of\n American values on European culture\" [syn: impingement,\n encroachment, impact]\n 4: the violent interaction of individuals or groups entering\n into combat; \"the armies met in the shock of battle\" [syn:\n shock, impact]\n v 1: press or wedge together; pack together\n 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n affect, impact, bear upon, bear on, touch on,\n touch]\n\nFrom Merriam-Webster dictionary:\n\n impact\n\n noun\n im·​pact | \\ ˈim-ˌpakt How to pronounce impact (audio) \\\n plural impacts\n\n 1a : an impinging or striking especially of one body against another\n b : a forceful contact or onset also : the impetus communicated in or as\n if in such a contact\n 2 : the force of impression of one thing on another : a significant or\n major effect the impact of science on our society a study outlining the\n potential environmental impacts of the construction project\n\n impact\n\n verb\n im·​pact | \\ im-ˈpakt How to pronounce impact (audio) \\\n impacted; impacting; impacts\n\n transitive verb\n\n 1a : to have a direct effect or impact on : impinge on\n b : to strike forcefully also : to cause to strike forcefully\n 2a : to fix firmly by or as if by packing or wedging\n b : to press together\n\n intransitive verb\n\n 1 : to have an impact —often used with on\n 2 : to impinge or make contact especially forcefully\n\nIf you are concerned about correctness and clarity of the documentation please\navoid spreading misinformation.\n\nThanks\n\nMichal\n\n> Signed-off-by: Varun Varada \n> ---\n> Documentation/MyFirstContribution.txt | 2 +-\n> Documentation/MyFirstObjectWalk.txt | 2 +-\n> Documentation/config/pack.txt | 2 +-\n> Documentation/git-fast-import.txt | 14 +++++++-------\n> Documentation/git-fetch.txt | 2 +-\n> .../technical/hash-function-transition.txt | 2 +-\n> Documentation/user-manual.txt | 4 ++--\n> advice.c | 2 +-\n> builtin/fast-import.c | 2 +-\n> builtin/pack-objects.c | 2 +-\n> compat/nedmalloc/malloc.c.h | 2 +-\n> contrib/coccinelle/README | 2 +-\n> dir.c | 2 +-\n> t/perf/p5550-fetch-tags.sh | 2 +-\n> t/t0008-ignores.sh | 2 +-\n> t/t0303-credential-external.sh | 2 +-\n> t/t2020-checkout-detach.sh | 4 ++--\n> t/t4013-diff-various.sh | 2 +-\n> t/t5000-tar-tree.sh | 2 +-\n> t/test-lib-functions.sh | 2 +-\n> 20 files changed, 28 insertions(+), 28 deletions(-)\n> \n> diff --git a/Documentation/MyFirstContribution.txt\n> b/Documentation/MyFirstContribution.txt\n> index af0a9da62e..8372a7e59e 100644\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> how to show it in the general\n> command list shown by `git help git` or `git help -a`, which is generated from\n> `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> line above it in alphabetical order. Now, we can add some attributes about the\n> -command which impacts where it shows up in the aforementioned help\n> commands. The\n> +command which affects where it shows up in the aforementioned help\n> commands. The\n> top of `command-list.txt` shares some information about what each attribute\n> means; in those help pages, the commands are sorted according to these\n> attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> diff --git a/Documentation/MyFirstObjectWalk.txt\n> b/Documentation/MyFirstObjectWalk.txt\n> index 2d10eea7a9..fd5bb8fb7d 100644\n> --- a/Documentation/MyFirstObjectWalk.txt\n> +++ b/Documentation/MyFirstObjectWalk.txt\n> @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> By running your walk with and without the filter, you should find\n> that the total\n> object count in each case is identical. You can also time each invocation of\n> the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> -to yourself the runtime impact of tracking all omitted objects.\n> +to yourself the runtime effect of tracking all omitted objects.\n> \n> === Changing the Order\n> \n> diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> index 3da4ea98e2..00fcc9d7c7 100644\n> --- a/Documentation/config/pack.txt\n> +++ b/Documentation/config/pack.txt\n> @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> This cache is used to speed up the writing object phase by not\n> having to recompute the final delta result once the best match\n> for all objects is found. Repacking large repositories on machines\n> - which are tight with memory might be badly impacted by this though,\n> + which are tight with memory might be badly affected by this though,\n> especially if this cache pushes the system into swapping.\n> A value of 0 means no limit. The smallest size of 1 byte may be\n> used to virtually disable this cache. Defaults to 256 MiB.\n> diff --git a/Documentation/git-fast-import.txt\n> b/Documentation/git-fast-import.txt\n> index 39cfa05b28..c6d8e4e1d7 100644\n> --- a/Documentation/git-fast-import.txt\n> +++ b/Documentation/git-fast-import.txt\n> @@ -58,7 +58,7 @@ OPTIONS\n> allowing fast-import to access the filesystem outside of the\n> repository). These options are disabled by default, but can be\n> allowed by providing this option on the command line. This\n> - currently impacts only the `export-marks`, `import-marks`, and\n> + currently affects only the `export-marks`, `import-marks`, and\n> `import-marks-if-exists` feature commands.\n> +\n> Only enable this option if you trust the program generating the\n> @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> \n> A `filecopy` command takes effect immediately. Once the source\n> location has been copied to the destination any future commands\n> -applied to the source location will not impact the destination of\n> +applied to the source location will not affect the destination of\n> the copy.\n> \n> `filerename`\n> @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> A `filerename` command takes effect immediately. Once the source\n> location has been renamed to the destination any future commands\n> applied to the source location will create new files there and not\n> -impact the destination of the rename.\n> +affect the destination of the rename.\n> \n> Note that a `filerename` is the same as a `filecopy` followed by a\n> `filedelete` of the source location. There is a slight performance\n> @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> to be required).\n> ~~~~~~~~~~\n> Causes fast-import to print the entire `progress` line unmodified to\n> its standard output channel (file descriptor 1) when the command is\n> -processed from the input stream. The command otherwise has no impact\n> +processed from the input stream. The command otherwise has no effect\n> on the current import, or on any of fast-import's internal state.\n> \n> ....\n> @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> ~~~~~~~~~~\n> Causes fast-import to print the SHA-1 corresponding to a mark to\n> stdout or to the file descriptor previously arranged with the\n> -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> current import; its purpose is to retrieve SHA-1s that later commits\n> might want to refer to in their commit messages.\n> \n> @@ -1050,7 +1050,7 @@ this output safely.\n> ~~~~~~~~~~\n> Causes fast-import to print a blob to a file descriptor previously\n> arranged with the `--cat-blob-fd` argument. The command otherwise\n> -has no impact on the current import; its main purpose is to\n> +has no effect on the current import; its main purpose is to\n> retrieve blobs that may be in fast-import's memory but not\n> accessible from the target repository.\n> \n> @@ -1366,7 +1366,7 @@ code considerably.\n> \n> The branch LRU builtin to fast-import tends to behave very well, and the\n> cost of activating an inactive branch is so low that bouncing around\n> -between branches has virtually no impact on import performance.\n> +between branches has virtually no effect on import performance.\n> \n> Handling Renames\n> ~~~~~~~~~~~~~~~~\n> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> index 9067c2079e..01cf3b3d16 100644\n> --- a/Documentation/git-fetch.txt\n> +++ b/Documentation/git-fetch.txt\n> @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> If left to accumulate, these stale references might make performance\n> worse on big and busy repos that have a lot of branch churn, and\n> e.g. make the output of commands like `git branch -a --contains\n> -` needlessly verbose, as well as impacting anything else\n> +` needlessly verbose, as well as affecting anything else\n> that'll work with the complete set of known references.\n> \n> These remote-tracking references can be deleted as a one-off with\n> diff --git a/Documentation/technical/hash-function-transition.txt\n> b/Documentation/technical/hash-function-transition.txt\n> index 7c1630bf83..f4296faffc 100644\n> --- a/Documentation/technical/hash-function-transition.txt\n> +++ b/Documentation/technical/hash-function-transition.txt\n> @@ -42,7 +42,7 @@ mitigations.\n> \n> If SHA-1 and its variants were to be truly broken, Git's hash function\n> could not be considered cryptographically secure any more. This would\n> -impact the communication of hash values because we could not trust\n> +affect the communication of hash values because we could not trust\n> that a given hash value represented the known good version of content\n> that the speaker intended.\n> \n> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> index fd480b8645..33c60c49d7 100644\n> --- a/Documentation/user-manual.txt\n> +++ b/Documentation/user-manual.txt\n> @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> \n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> -state without impacting any branches by performing another switch.\n> +state without affecting any branches by performing another switch.\n> \n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command again. Example:\n> @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> overwritten by the result of\n> the merge when this combining is done cleanly, or overwritten by a\n> half-merged results when this combining results in conflicts.\n> Therefore, if you have uncommitted changes touching the same files as\n> -the ones impacted by the merge, Git will refuse to proceed. Most of\n> +the ones affected by the merge, Git will refuse to proceed. Most of\n> the time, you will want to commit your changes before you can merge,\n> and if you don't, then linkgit:git-stash[1] can take these changes\n> away while you're doing the merge, and reapply them afterwards.\n> diff --git a/advice.c b/advice.c\n> index 164742305f..9cbbb824a9 100644\n> --- a/advice.c\n> +++ b/advice.c\n> @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> \"\\n\"\n> \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> \"changes and commit them, and you can discard any commits you make in this\\n\"\n> - \"state without impacting any branches by switching back to a branch.\\n\"\n> + \"state without affecting any branches by switching back to a branch.\\n\"\n> \"\\n\"\n> \"If you want to create a new branch to retain commits you create, you may\\n\"\n> \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> index 3afa81cf9a..24f362d2f4 100644\n> --- a/builtin/fast-import.c\n> +++ b/builtin/fast-import.c\n> @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> const char *prefix)\n> * We don't parse most options until after we've seen the set of\n> * \"feature\" lines at the start of the stream (which allows the command\n> * line to override stream data). But we must do an early parse of any\n> - * command-line options that impact how we interpret the feature lines.\n> + * command-line options that affect how we interpret the feature lines.\n> */\n> for (i = 1; i < argc; i++) {\n> const char *arg = argv[i];\n> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> index 525c2d8552..749bbca241 100644\n> --- a/builtin/pack-objects.c\n> +++ b/builtin/pack-objects.c\n> @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> /*\n> * Mark ourselves as active and see if the next step causes\n> * us to cycle to another active object. It's important to do\n> - * this _before_ we loop, because it impacts where we make the\n> + * this _before_ we loop, because it affects where we make the\n> * cut, and thus how our total_depth counter works.\n> * E.g., We may see a partial loop like:\n> *\n> diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h\n> index 814845d4b3..de13121d76 100644\n> --- a/compat/nedmalloc/malloc.c.h\n> +++ b/compat/nedmalloc/malloc.c.h\n> @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> #endif /* (FOOTERS && !INSECURE) */\n> \n> \n> -/* In gcc, use __builtin_expect to minimize impact of checks */\n> +/* In gcc, use __builtin_expect to minimize affect of checks */\n> #if !INSECURE\n> #if defined(__GNUC__) && __GNUC__ >= 3\n> #define RTCHECK(e) __builtin_expect(e, 1)\n> diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> index f0e80bd7f0..92979ec770 100644\n> --- a/contrib/coccinelle/README\n> +++ b/contrib/coccinelle/README\n> @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> \n> This allows to expose plans of pending large scale refactorings without\n> - impacting the bad pattern checks.\n> + affecting the bad pattern checks.\n> diff --git a/dir.c b/dir.c\n> index 3474e67e8f..235e26a90e 100644\n> --- a/dir.c\n> +++ b/dir.c\n> @@ -2144,7 +2144,7 @@ static enum path_treatment\n> treat_path_fast(struct dir_struct *dir,\n> /*\n> * We get path_recurse in the first run when\n> * directory_exists_in_index() returns index_nonexistent. We\n> - * are sure that new changes in the index does not impact the\n> + * are sure that new changes in the index does not affect the\n> * outcome. Return now.\n> */\n> return path_recurse;\n> diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> index d0e0e019ea..1fcb98443c 100755\n> --- a/t/perf/p5550-fetch-tags.sh\n> +++ b/t/perf/p5550-fetch-tags.sh\n> @@ -8,7 +8,7 @@ follows.\n> \n> The parent repository has a large number of tags which are disconnected from\n> the rest of history. That makes them candidates for tag-following, but we never\n> -actually grab them (and thus they will impact each subsequent fetch).\n> +actually grab them (and thus they will affect each subsequent fetch).\n> \n> The child repository is a clone of parent, without the tags, and is at least\n> one commit behind the parent (meaning that we will fetch one object and then\n> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> index a594b4aa7d..95daba4000 100755\n> --- a/t/t0008-ignores.sh\n> +++ b/t/t0008-ignores.sh\n> @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> # test standard ignores\n> \n> # First make sure that the presence of a file in the working tree\n> -# does not impact results, but that the presence of a file in the\n> +# does not affect results, but that the presence of a file in the\n> # index does unless the --no-index option is used.\n> \n> for subdir in '' 'a/'\n> diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> index f028fd1418..a9348f655a 100755\n> --- a/t/t0303-credential-external.sh\n> +++ b/t/t0303-credential-external.sh\n> @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> \n> # clean before the test in case there is cruft left\n> -# over from a previous run that would impact results\n> +# over from a previous run that would affect results\n> helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> \n> helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> index bc46713a43..568c258c5a 100755\n> --- a/t/t2020-checkout-detach.sh\n> +++ b/t/t2020-checkout-detach.sh\n> @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> no SHA-1 ellipsis when not as\n> \n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> - state without impacting any branches by switching back to a branch.\n> + state without affecting any branches by switching back to a branch.\n> \n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command. Example:\n> @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> print SHA-1 ellipsis when asked\n> \n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> - state without impacting any branches by switching back to a branch.\n> + state without affecting any branches by switching back to a branch.\n> \n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command. Example:\n> diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> index 6cca8b84a6..97365a7786 100755\n> --- a/t/t4013-diff-various.sh\n> +++ b/t/t4013-diff-various.sh\n> @@ -109,7 +109,7 @@ test_expect_success setup '\n> git checkout -f master &&\n> \n> # Same merge as master, but with parents reversed. Hide it in a\n> - # pseudo-ref to avoid impacting tests with --all.\n> + # pseudo-ref to avoid affecting tests with --all.\n> commit=$(echo reverse |\n> git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> git update-ref REVERSE $commit &&\n> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> index 7204799a0b..33a6efce2f 100755\n> --- a/t/t5000-tar-tree.sh\n> +++ b/t/t5000-tar-tree.sh\n> @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> # Pull the size and date of each entry in a tarfile using the system tar.\n> #\n> # We'll pull out only the year from the date; that avoids any question of\n> -# timezones impacting the result (as long as we keep our test times away from a\n> +# timezones affecting the result (as long as we keep our test times away from a\n> # year boundary; our reference times are all in August).\n> #\n> # The output of tar_info is expected to be \" \", both in decimal. It\n> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> index 6348e8d733..ff65f86f50 100644\n> --- a/t/test-lib-functions.sh\n> +++ b/t/test-lib-functions.sh\n> @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> }\n> \n> # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> -# it also works for shell functions (though those functions cannot impact\n> +# it also works for shell functions (though those functions cannot affect\n> # the environment outside of the test_env invocation).\n> test_env () {\n> (\n> -- \n> 2.17.1\n> \n> \n> From varun Mon Apr 5 16:45:37 2021\n> Return-Path: \n> Received: (from varun@localhost)\n> by black-diamond (8.15.2/8.15.2/Submit) id 135LjbIS027022;\n> Mon, 5 Apr 2021 16:45:37 -0500\n> From: Varun Varada \n> To: git@vger.kernel.org\n> Cc: Varun Varada \n> Subject: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"\n> Date: Mon, 5 Apr 2021 16:44:35 -0500\n> Message-Id: <20210405214435.26979-1-varuncvarada@gmail.com>\n> X-Mailer: git-send-email 2.17.1\n> \n> There are a bunch of places in the code/docs which use the word \"impact\"\n> incorrectly. This is especially true of places where it says \"will not\n> impact\", which suggests that it might have an effect, albeit not as\n> strong of a one. This commit replaces all of these with their\n> appropriate alternative so that the docs not only does not use jargon,\n> but are also unambiguous.\n> \n> Signed-off-by: Varun Varada \n> ---\n> Documentation/MyFirstContribution.txt | 2 +-\n> Documentation/MyFirstObjectWalk.txt | 2 +-\n> Documentation/config/pack.txt | 2 +-\n> Documentation/git-fast-import.txt | 14 +++++++-------\n> Documentation/git-fetch.txt | 2 +-\n> .../technical/hash-function-transition.txt | 2 +-\n> Documentation/user-manual.txt | 4 ++--\n> advice.c | 2 +-\n> builtin/fast-import.c | 2 +-\n> builtin/pack-objects.c | 2 +-\n> compat/nedmalloc/malloc.c.h | 2 +-\n> contrib/coccinelle/README | 2 +-\n> dir.c | 2 +-\n> t/perf/p5550-fetch-tags.sh | 2 +-\n> t/t0008-ignores.sh | 2 +-\n> t/t0303-credential-external.sh | 2 +-\n> t/t2020-checkout-detach.sh | 4 ++--\n> t/t4013-diff-various.sh | 2 +-\n> t/t5000-tar-tree.sh | 2 +-\n> t/test-lib-functions.sh | 2 +-\n> 20 files changed, 28 insertions(+), 28 deletions(-)\n> \n> diff --git a/Documentation/MyFirstContribution.txt\n> b/Documentation/MyFirstContribution.txt\n> index af0a9da62e..8372a7e59e 100644\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> how to show it in the general\n> command list shown by `git help git` or `git help -a`, which is generated from\n> `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> line above it in alphabetical order. Now, we can add some attributes about the\n> -command which impacts where it shows up in the aforementioned help\n> commands. The\n> +command which affects where it shows up in the aforementioned help\n> commands. The\n> top of `command-list.txt` shares some information about what each attribute\n> means; in those help pages, the commands are sorted according to these\n> attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> diff --git a/Documentation/MyFirstObjectWalk.txt\n> b/Documentation/MyFirstObjectWalk.txt\n> index 2d10eea7a9..fd5bb8fb7d 100644\n> --- a/Documentation/MyFirstObjectWalk.txt\n> +++ b/Documentation/MyFirstObjectWalk.txt\n> @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> By running your walk with and without the filter, you should find\n> that the total\n> object count in each case is identical. You can also time each invocation of\n> the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> -to yourself the runtime impact of tracking all omitted objects.\n> +to yourself the runtime effect of tracking all omitted objects.\n> \n> === Changing the Order\n> \n> diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> index 3da4ea98e2..00fcc9d7c7 100644\n> --- a/Documentation/config/pack.txt\n> +++ b/Documentation/config/pack.txt\n> @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> This cache is used to speed up the writing object phase by not\n> having to recompute the final delta result once the best match\n> for all objects is found. Repacking large repositories on machines\n> - which are tight with memory might be badly impacted by this though,\n> + which are tight with memory might be badly affected by this though,\n> especially if this cache pushes the system into swapping.\n> A value of 0 means no limit. The smallest size of 1 byte may be\n> used to virtually disable this cache. Defaults to 256 MiB.\n> diff --git a/Documentation/git-fast-import.txt\n> b/Documentation/git-fast-import.txt\n> index 39cfa05b28..c6d8e4e1d7 100644\n> --- a/Documentation/git-fast-import.txt\n> +++ b/Documentation/git-fast-import.txt\n> @@ -58,7 +58,7 @@ OPTIONS\n> allowing fast-import to access the filesystem outside of the\n> repository). These options are disabled by default, but can be\n> allowed by providing this option on the command line. This\n> - currently impacts only the `export-marks`, `import-marks`, and\n> + currently affects only the `export-marks`, `import-marks`, and\n> `import-marks-if-exists` feature commands.\n> +\n> Only enable this option if you trust the program generating the\n> @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> \n> A `filecopy` command takes effect immediately. Once the source\n> location has been copied to the destination any future commands\n> -applied to the source location will not impact the destination of\n> +applied to the source location will not affect the destination of\n> the copy.\n> \n> `filerename`\n> @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> A `filerename` command takes effect immediately. Once the source\n> location has been renamed to the destination any future commands\n> applied to the source location will create new files there and not\n> -impact the destination of the rename.\n> +affect the destination of the rename.\n> \n> Note that a `filerename` is the same as a `filecopy` followed by a\n> `filedelete` of the source location. There is a slight performance\n> @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> to be required).\n> ~~~~~~~~~~\n> Causes fast-import to print the entire `progress` line unmodified to\n> its standard output channel (file descriptor 1) when the command is\n> -processed from the input stream. The command otherwise has no impact\n> +processed from the input stream. The command otherwise has no effect\n> on the current import, or on any of fast-import's internal state.\n> \n> ....\n> @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> ~~~~~~~~~~\n> Causes fast-import to print the SHA-1 corresponding to a mark to\n> stdout or to the file descriptor previously arranged with the\n> -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> current import; its purpose is to retrieve SHA-1s that later commits\n> might want to refer to in their commit messages.\n> \n> @@ -1050,7 +1050,7 @@ this output safely.\n> ~~~~~~~~~~\n> Causes fast-import to print a blob to a file descriptor previously\n> arranged with the `--cat-blob-fd` argument. The command otherwise\n> -has no impact on the current import; its main purpose is to\n> +has no effect on the current import; its main purpose is to\n> retrieve blobs that may be in fast-import's memory but not\n> accessible from the target repository.\n> \n> @@ -1366,7 +1366,7 @@ code considerably.\n> \n> The branch LRU builtin to fast-import tends to behave very well, and the\n> cost of activating an inactive branch is so low that bouncing around\n> -between branches has virtually no impact on import performance.\n> +between branches has virtually no effect on import performance.\n> \n> Handling Renames\n> ~~~~~~~~~~~~~~~~\n> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> index 9067c2079e..01cf3b3d16 100644\n> --- a/Documentation/git-fetch.txt\n> +++ b/Documentation/git-fetch.txt\n> @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> If left to accumulate, these stale references might make performance\n> worse on big and busy repos that have a lot of branch churn, and\n> e.g. make the output of commands like `git branch -a --contains\n> -` needlessly verbose, as well as impacting anything else\n> +` needlessly verbose, as well as affecting anything else\n> that'll work with the complete set of known references.\n> \n> These remote-tracking references can be deleted as a one-off with\n> diff --git a/Documentation/technical/hash-function-transition.txt\n> b/Documentation/technical/hash-function-transition.txt\n> index 7c1630bf83..f4296faffc 100644\n> --- a/Documentation/technical/hash-function-transition.txt\n> +++ b/Documentation/technical/hash-function-transition.txt\n> @@ -42,7 +42,7 @@ mitigations.\n> \n> If SHA-1 and its variants were to be truly broken, Git's hash function\n> could not be considered cryptographically secure any more. This would\n> -impact the communication of hash values because we could not trust\n> +affect the communication of hash values because we could not trust\n> that a given hash value represented the known good version of content\n> that the speaker intended.\n> \n> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> index fd480b8645..33c60c49d7 100644\n> --- a/Documentation/user-manual.txt\n> +++ b/Documentation/user-manual.txt\n> @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> \n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> -state without impacting any branches by performing another switch.\n> +state without affecting any branches by performing another switch.\n> \n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command again. Example:\n> @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> overwritten by the result of\n> the merge when this combining is done cleanly, or overwritten by a\n> half-merged results when this combining results in conflicts.\n> Therefore, if you have uncommitted changes touching the same files as\n> -the ones impacted by the merge, Git will refuse to proceed. Most of\n> +the ones affected by the merge, Git will refuse to proceed. Most of\n> the time, you will want to commit your changes before you can merge,\n> and if you don't, then linkgit:git-stash[1] can take these changes\n> away while you're doing the merge, and reapply them afterwards.\n> diff --git a/advice.c b/advice.c\n> index 164742305f..9cbbb824a9 100644\n> --- a/advice.c\n> +++ b/advice.c\n> @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> \"\\n\"\n> \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> \"changes and commit them, and you can discard any commits you make in this\\n\"\n> - \"state without impacting any branches by switching back to a branch.\\n\"\n> + \"state without affecting any branches by switching back to a branch.\\n\"\n> \"\\n\"\n> \"If you want to create a new branch to retain commits you create, you may\\n\"\n> \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> index 3afa81cf9a..24f362d2f4 100644\n> --- a/builtin/fast-import.c\n> +++ b/builtin/fast-import.c\n> @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> const char *prefix)\n> * We don't parse most options until after we've seen the set of\n> * \"feature\" lines at the start of the stream (which allows the command\n> * line to override stream data). But we must do an early parse of any\n> - * command-line options that impact how we interpret the feature lines.\n> + * command-line options that affect how we interpret the feature lines.\n> */\n> for (i = 1; i < argc; i++) {\n> const char *arg = argv[i];\n> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> index 525c2d8552..749bbca241 100644\n> --- a/builtin/pack-objects.c\n> +++ b/builtin/pack-objects.c\n> @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> /*\n> * Mark ourselves as active and see if the next step causes\n> * us to cycle to another active object. It's important to do\n> - * this _before_ we loop, because it impacts where we make the\n> + * this _before_ we loop, because it affects where we make the\n> * cut, and thus how our total_depth counter works.\n> * E.g., We may see a partial loop like:\n> *\n> diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h\n> index 814845d4b3..de13121d76 100644\n> --- a/compat/nedmalloc/malloc.c.h\n> +++ b/compat/nedmalloc/malloc.c.h\n> @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> #endif /* (FOOTERS && !INSECURE) */\n> \n> \n> -/* In gcc, use __builtin_expect to minimize impact of checks */\n> +/* In gcc, use __builtin_expect to minimize affect of checks */\n> #if !INSECURE\n> #if defined(__GNUC__) && __GNUC__ >= 3\n> #define RTCHECK(e) __builtin_expect(e, 1)\n> diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> index f0e80bd7f0..92979ec770 100644\n> --- a/contrib/coccinelle/README\n> +++ b/contrib/coccinelle/README\n> @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> \n> This allows to expose plans of pending large scale refactorings without\n> - impacting the bad pattern checks.\n> + affecting the bad pattern checks.\n> diff --git a/dir.c b/dir.c\n> index 3474e67e8f..235e26a90e 100644\n> --- a/dir.c\n> +++ b/dir.c\n> @@ -2144,7 +2144,7 @@ static enum path_treatment\n> treat_path_fast(struct dir_struct *dir,\n> /*\n> * We get path_recurse in the first run when\n> * directory_exists_in_index() returns index_nonexistent. We\n> - * are sure that new changes in the index does not impact the\n> + * are sure that new changes in the index does not affect the\n> * outcome. Return now.\n> */\n> return path_recurse;\n> diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> index d0e0e019ea..1fcb98443c 100755\n> --- a/t/perf/p5550-fetch-tags.sh\n> +++ b/t/perf/p5550-fetch-tags.sh\n> @@ -8,7 +8,7 @@ follows.\n> \n> The parent repository has a large number of tags which are disconnected from\n> the rest of history. That makes them candidates for tag-following, but we never\n> -actually grab them (and thus they will impact each subsequent fetch).\n> +actually grab them (and thus they will affect each subsequent fetch).\n> \n> The child repository is a clone of parent, without the tags, and is at least\n> one commit behind the parent (meaning that we will fetch one object and then\n> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> index a594b4aa7d..95daba4000 100755\n> --- a/t/t0008-ignores.sh\n> +++ b/t/t0008-ignores.sh\n> @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> # test standard ignores\n> \n> # First make sure that the presence of a file in the working tree\n> -# does not impact results, but that the presence of a file in the\n> +# does not affect results, but that the presence of a file in the\n> # index does unless the --no-index option is used.\n> \n> for subdir in '' 'a/'\n> diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> index f028fd1418..a9348f655a 100755\n> --- a/t/t0303-credential-external.sh\n> +++ b/t/t0303-credential-external.sh\n> @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> \n> # clean before the test in case there is cruft left\n> -# over from a previous run that would impact results\n> +# over from a previous run that would affect results\n> helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> \n> helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> index bc46713a43..568c258c5a 100755\n> --- a/t/t2020-checkout-detach.sh\n> +++ b/t/t2020-checkout-detach.sh\n> @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> no SHA-1 ellipsis when not as\n> \n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> - state without impacting any branches by switching back to a branch.\n> + state without affecting any branches by switching back to a branch.\n> \n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command. Example:\n> @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> print SHA-1 ellipsis when asked\n> \n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> - state without impacting any branches by switching back to a branch.\n> + state without affecting any branches by switching back to a branch.\n> \n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command. Example:\n> diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> index 6cca8b84a6..97365a7786 100755\n> --- a/t/t4013-diff-various.sh\n> +++ b/t/t4013-diff-various.sh\n> @@ -109,7 +109,7 @@ test_expect_success setup '\n> git checkout -f master &&\n> \n> # Same merge as master, but with parents reversed. Hide it in a\n> - # pseudo-ref to avoid impacting tests with --all.\n> + # pseudo-ref to avoid affecting tests with --all.\n> commit=$(echo reverse |\n> git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> git update-ref REVERSE $commit &&\n> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> index 7204799a0b..33a6efce2f 100755\n> --- a/t/t5000-tar-tree.sh\n> +++ b/t/t5000-tar-tree.sh\n> @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> # Pull the size and date of each entry in a tarfile using the system tar.\n> #\n> # We'll pull out only the year from the date; that avoids any question of\n> -# timezones impacting the result (as long as we keep our test times away from a\n> +# timezones affecting the result (as long as we keep our test times away from a\n> # year boundary; our reference times are all in August).\n> #\n> # The output of tar_info is expected to be \" \", both in decimal. It\n> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> index 6348e8d733..ff65f86f50 100644\n> --- a/t/test-lib-functions.sh\n> +++ b/t/test-lib-functions.sh\n> @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> }\n> \n> # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> -# it also works for shell functions (though those functions cannot impact\n> +# it also works for shell functions (though those functions cannot affect\n> # the environment outside of the test_env invocation).\n> test_env () {\n> (\n> -- \n> 2.17.1\n> \n"},{"id":"421089","messageId":"CAD2i4DDr3Ftk6RE8cA74iSsJTpC9nEb=Cqvr79pF51BpcWEnsA@mail.gmail.com","threadId":"55436","inReplyTo":"20210406092440.GZ6564@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-04-06T19:36:27Z","receivedAt":"2021-04-06T19:36:46Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Tue, 6 Apr 2021 at 04:24, Michal Suchánek wrote:\n>\n> On Mon, Apr 05, 2021 at 04:48:58PM -0500, Varun Varada wrote:\n> > There are a bunch of places in the code/docs which use the word \"impact\"\n> > incorrectly. This is especially true of places where it says \"will not\n> > impact\", which suggests that it might have an effect, albeit not as\n> > strong of a one. This commit replaces all of these with their\n> > appropriate alternative so that the docs not only does not use jargon,\n> > but are also unambiguous.\n>\n> Hello,\n>\n> while using \"will not impact\" in an incorrect or unclear way may be a\n> problem the word \"impact\" in itself is not \"jargon\".\n\nThe word means \"to have a strong or marked effect on\" (v.) and \"a\nstrong or market influence\" (n.) when used figuratively; it is not\nsynonymous with \"affect\" and \"effect\", respectively, as shown even by\nall of the entries you've cited. Using it as such is the incorrect\npart, so those are the instances I've changed in the diff.\n\n>\n> From The Collaborative International Dictionary of English v.0.48 :\n>\n> Impact \\Im*pact\"\\, v. t. [imp. & p. p. Impacted; p. pr. & vb.\n> n. Impacting.] [L. impactus, p. p. of impingere to push,\n> strike against. See Impinge.]\n> 1. To drive close; to press firmly together: to wedge into a\n> place. --Woodward.\n> [1913 Webster]\n>\n> 2. To affect or influence, especially in a significant or\n> undesirable manner; as, budget cuts impacted the entire\n> research program; the fish populations were adversely\n> impacted by pollution.\n> [PJC]\n>\n> 3. To collide forcefully with; to strike.\n> [PJC]\n>\n> From WordNet (r) 3.0 (2006) :\n>\n> impact\n> n 1: the striking of one body against another\n> 2: a forceful consequence; a strong effect; \"the book had an\n> important impact on my thinking\"; \"the book packs a wallop\"\n> [syn: impact, wallop]\n> 3: influencing strongly; \"they resented the impingement of\n> American values on European culture\" [syn: impingement,\n> encroachment, impact]\n> 4: the violent interaction of individuals or groups entering\n> into combat; \"the armies met in the shock of battle\" [syn:\n> shock, impact]\n> v 1: press or wedge together; pack together\n> 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> affect, impact, bear upon, bear on, touch on,\n> touch]\n>\n> From Merriam-Webster dictionary:\n>\n> impact\n>\n> noun\n> im·pact | \\ ˈim-ˌpakt How to pronounce impact (audio) \\\n> plural impacts\n>\n> 1a : an impinging or striking especially of one body against another\n> b : a forceful contact or onset also : the impetus communicated in or as\n> if in such a contact\n> 2 : the force of impression of one thing on another : a significant or\n> major effect the impact of science on our society a study outlining the\n> potential environmental impacts of the construction project\n>\n> impact\n>\n> verb\n> im·pact | \\ im-ˈpakt How to pronounce impact (audio) \\\n> impacted; impacting; impacts\n>\n> transitive verb\n>\n> 1a : to have a direct effect or impact on : impinge on\n> b : to strike forcefully also : to cause to strike forcefully\n> 2a : to fix firmly by or as if by packing or wedging\n> b : to press together\n>\n> intransitive verb\n>\n> 1 : to have an impact —often used with on\n> 2 : to impinge or make contact especially forcefully\n>\n> If you are concerned about correctness and clarity of the documentation please\n> avoid spreading misinformation.\n\nAs for jargon, using the noun and the verb in a figurative sense is\nstill in the realm of (business) jargon for most publications:\n\nFrom Lexico, powered by Oxford English Dictionary:\n\nThe phrasal verb impact on, as in when produce is lost, it always\nimpacts on the bottom line, has been in the language since the 1960s.\nMany people disapprove of it, saying that make an impact on or other\nequivalent wordings should be used instead. This may be partly\nbecause, in general, new formations of verbs from nouns (as in the\ncase of impact, action, and task) are regarded as somehow inferior; in\naddition, since the verbal use of impact is associated with business\nand commercial writing, it has the unenviable status of ‘jargon’,\nwhich makes it doubly disliked.\n\n\nFrom the Modern Language Association (MLA):\n\nIn its publications, the MLA follows various usage experts who\nrecommend restricting the use of impact as a verb to only one of the\nseveral definitions you may find in a dictionary: “to strike\nforcefully” (“Impact”). A car may impact another car in a collision,\nfor example. But we avoid using impact as a verb when the meaning is\n“to affect” or “to influence.”\n\n\nFrom MIT / the Mayfield Handbook of Technical and Scientific Writing:\n\nDo not confuse the words affect, effect, and impact, each of which can\nbe used both as a verb and as a noun. Avoid incorrectly using impact\nas a verb in place of affect or as a noun in place of effect.\n\n>\n> Thanks\n>\n> Michal\n>\n> > Signed-off-by: Varun Varada \n> > ---\n> > Documentation/MyFirstContribution.txt | 2 +-\n> > Documentation/MyFirstObjectWalk.txt | 2 +-\n> > Documentation/config/pack.txt | 2 +-\n> > Documentation/git-fast-import.txt | 14 +++++++-------\n> > Documentation/git-fetch.txt | 2 +-\n> > .../technical/hash-function-transition.txt | 2 +-\n> > Documentation/user-manual.txt | 4 ++--\n> > advice.c | 2 +-\n> > builtin/fast-import.c | 2 +-\n> > builtin/pack-objects.c | 2 +-\n> > compat/nedmalloc/malloc.c.h | 2 +-\n> > contrib/coccinelle/README | 2 +-\n> > dir.c | 2 +-\n> > t/perf/p5550-fetch-tags.sh | 2 +-\n> > t/t0008-ignores.sh | 2 +-\n> > t/t0303-credential-external.sh | 2 +-\n> > t/t2020-checkout-detach.sh | 4 ++--\n> > t/t4013-diff-various.sh | 2 +-\n> > t/t5000-tar-tree.sh | 2 +-\n> > t/test-lib-functions.sh | 2 +-\n> > 20 files changed, 28 insertions(+), 28 deletions(-)\n> >\n> > diff --git a/Documentation/MyFirstContribution.txt\n> > b/Documentation/MyFirstContribution.txt\n> > index af0a9da62e..8372a7e59e 100644\n> > --- a/Documentation/MyFirstContribution.txt\n> > +++ b/Documentation/MyFirstContribution.txt\n> > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> > how to show it in the general\n> > command list shown by `git help git` or `git help -a`, which is generated from\n> > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> > line above it in alphabetical order. Now, we can add some attributes about the\n> > -command which impacts where it shows up in the aforementioned help\n> > commands. The\n> > +command which affects where it shows up in the aforementioned help\n> > commands. The\n> > top of `command-list.txt` shares some information about what each attribute\n> > means; in those help pages, the commands are sorted according to these\n> > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> > diff --git a/Documentation/MyFirstObjectWalk.txt\n> > b/Documentation/MyFirstObjectWalk.txt\n> > index 2d10eea7a9..fd5bb8fb7d 100644\n> > --- a/Documentation/MyFirstObjectWalk.txt\n> > +++ b/Documentation/MyFirstObjectWalk.txt\n> > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> > By running your walk with and without the filter, you should find\n> > that the total\n> > object count in each case is identical. You can also time each invocation of\n> > the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> > -to yourself the runtime impact of tracking all omitted objects.\n> > +to yourself the runtime effect of tracking all omitted objects.\n> >\n> > === Changing the Order\n> >\n> > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> > index 3da4ea98e2..00fcc9d7c7 100644\n> > --- a/Documentation/config/pack.txt\n> > +++ b/Documentation/config/pack.txt\n> > @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> > This cache is used to speed up the writing object phase by not\n> > having to recompute the final delta result once the best match\n> > for all objects is found. Repacking large repositories on machines\n> > - which are tight with memory might be badly impacted by this though,\n> > + which are tight with memory might be badly affected by this though,\n> > especially if this cache pushes the system into swapping.\n> > A value of 0 means no limit. The smallest size of 1 byte may be\n> > used to virtually disable this cache. Defaults to 256 MiB.\n> > diff --git a/Documentation/git-fast-import.txt\n> > b/Documentation/git-fast-import.txt\n> > index 39cfa05b28..c6d8e4e1d7 100644\n> > --- a/Documentation/git-fast-import.txt\n> > +++ b/Documentation/git-fast-import.txt\n> > @@ -58,7 +58,7 @@ OPTIONS\n> > allowing fast-import to access the filesystem outside of the\n> > repository). These options are disabled by default, but can be\n> > allowed by providing this option on the command line. This\n> > - currently impacts only the `export-marks`, `import-marks`, and\n> > + currently affects only the `export-marks`, `import-marks`, and\n> > `import-marks-if-exists` feature commands.\n> > +\n> > Only enable this option if you trust the program generating the\n> > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> >\n> > A `filecopy` command takes effect immediately. Once the source\n> > location has been copied to the destination any future commands\n> > -applied to the source location will not impact the destination of\n> > +applied to the source location will not affect the destination of\n> > the copy.\n> >\n> > `filerename`\n> > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> > A `filerename` command takes effect immediately. Once the source\n> > location has been renamed to the destination any future commands\n> > applied to the source location will create new files there and not\n> > -impact the destination of the rename.\n> > +affect the destination of the rename.\n> >\n> > Note that a `filerename` is the same as a `filecopy` followed by a\n> > `filedelete` of the source location. There is a slight performance\n> > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> > to be required).\n> > ~~~~~~~~~~\n> > Causes fast-import to print the entire `progress` line unmodified to\n> > its standard output channel (file descriptor 1) when the command is\n> > -processed from the input stream. The command otherwise has no impact\n> > +processed from the input stream. The command otherwise has no effect\n> > on the current import, or on any of fast-import's internal state.\n> >\n> > ....\n> > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> > ~~~~~~~~~~\n> > Causes fast-import to print the SHA-1 corresponding to a mark to\n> > stdout or to the file descriptor previously arranged with the\n> > -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> > +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> > current import; its purpose is to retrieve SHA-1s that later commits\n> > might want to refer to in their commit messages.\n> >\n> > @@ -1050,7 +1050,7 @@ this output safely.\n> > ~~~~~~~~~~\n> > Causes fast-import to print a blob to a file descriptor previously\n> > arranged with the `--cat-blob-fd` argument. The command otherwise\n> > -has no impact on the current import; its main purpose is to\n> > +has no effect on the current import; its main purpose is to\n> > retrieve blobs that may be in fast-import's memory but not\n> > accessible from the target repository.\n> >\n> > @@ -1366,7 +1366,7 @@ code considerably.\n> >\n> > The branch LRU builtin to fast-import tends to behave very well, and the\n> > cost of activating an inactive branch is so low that bouncing around\n> > -between branches has virtually no impact on import performance.\n> > +between branches has virtually no effect on import performance.\n> >\n> > Handling Renames\n> > ~~~~~~~~~~~~~~~~\n> > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> > index 9067c2079e..01cf3b3d16 100644\n> > --- a/Documentation/git-fetch.txt\n> > +++ b/Documentation/git-fetch.txt\n> > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> > If left to accumulate, these stale references might make performance\n> > worse on big and busy repos that have a lot of branch churn, and\n> > e.g. make the output of commands like `git branch -a --contains\n> > -` needlessly verbose, as well as impacting anything else\n> > +` needlessly verbose, as well as affecting anything else\n> > that'll work with the complete set of known references.\n> >\n> > These remote-tracking references can be deleted as a one-off with\n> > diff --git a/Documentation/technical/hash-function-transition.txt\n> > b/Documentation/technical/hash-function-transition.txt\n> > index 7c1630bf83..f4296faffc 100644\n> > --- a/Documentation/technical/hash-function-transition.txt\n> > +++ b/Documentation/technical/hash-function-transition.txt\n> > @@ -42,7 +42,7 @@ mitigations.\n> >\n> > If SHA-1 and its variants were to be truly broken, Git's hash function\n> > could not be considered cryptographically secure any more. This would\n> > -impact the communication of hash values because we could not trust\n> > +affect the communication of hash values because we could not trust\n> > that a given hash value represented the known good version of content\n> > that the speaker intended.\n> >\n> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > index fd480b8645..33c60c49d7 100644\n> > --- a/Documentation/user-manual.txt\n> > +++ b/Documentation/user-manual.txt\n> > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> >\n> > You are in 'detached HEAD' state. You can look around, make experimental\n> > changes and commit them, and you can discard any commits you make in this\n> > -state without impacting any branches by performing another switch.\n> > +state without affecting any branches by performing another switch.\n> >\n> > If you want to create a new branch to retain commits you create, you may\n> > do so (now or later) by using -c with the switch command again. Example:\n> > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> > overwritten by the result of\n> > the merge when this combining is done cleanly, or overwritten by a\n> > half-merged results when this combining results in conflicts.\n> > Therefore, if you have uncommitted changes touching the same files as\n> > -the ones impacted by the merge, Git will refuse to proceed. Most of\n> > +the ones affected by the merge, Git will refuse to proceed. Most of\n> > the time, you will want to commit your changes before you can merge,\n> > and if you don't, then linkgit:git-stash[1] can take these changes\n> > away while you're doing the merge, and reapply them afterwards.\n> > diff --git a/advice.c b/advice.c\n> > index 164742305f..9cbbb824a9 100644\n> > --- a/advice.c\n> > +++ b/advice.c\n> > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> > \"\\n\"\n> > \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> > \"changes and commit them, and you can discard any commits you make in this\\n\"\n> > - \"state without impacting any branches by switching back to a branch.\\n\"\n> > + \"state without affecting any branches by switching back to a branch.\\n\"\n> > \"\\n\"\n> > \"If you want to create a new branch to retain commits you create, you may\\n\"\n> > \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> > diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> > index 3afa81cf9a..24f362d2f4 100644\n> > --- a/builtin/fast-import.c\n> > +++ b/builtin/fast-import.c\n> > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> > const char *prefix)\n> > * We don't parse most options until after we've seen the set of\n> > * \"feature\" lines at the start of the stream (which allows the command\n> > * line to override stream data). But we must do an early parse of any\n> > - * command-line options that impact how we interpret the feature lines.\n> > + * command-line options that affect how we interpret the feature lines.\n> > */\n> > for (i = 1; i < argc; i++) {\n> > const char *arg = argv[i];\n> > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> > index 525c2d8552..749bbca241 100644\n> > --- a/builtin/pack-objects.c\n> > +++ b/builtin/pack-objects.c\n> > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> > /*\n> > * Mark ourselves as active and see if the next step causes\n> > * us to cycle to another active object. It's important to do\n> > - * this _before_ we loop, because it impacts where we make the\n> > + * this _before_ we loop, because it affects where we make the\n> > * cut, and thus how our total_depth counter works.\n> > * E.g., We may see a partial loop like:\n> > *\n> > diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h\n> > index 814845d4b3..de13121d76 100644\n> > --- a/compat/nedmalloc/malloc.c.h\n> > +++ b/compat/nedmalloc/malloc.c.h\n> > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > #endif /* (FOOTERS && !INSECURE) */\n> >\n> >\n> > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > #if !INSECURE\n> > #if defined(__GNUC__) && __GNUC__ >= 3\n> > #define RTCHECK(e) __builtin_expect(e, 1)\n> > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> > index f0e80bd7f0..92979ec770 100644\n> > --- a/contrib/coccinelle/README\n> > +++ b/contrib/coccinelle/README\n> > @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> > are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> >\n> > This allows to expose plans of pending large scale refactorings without\n> > - impacting the bad pattern checks.\n> > + affecting the bad pattern checks.\n> > diff --git a/dir.c b/dir.c\n> > index 3474e67e8f..235e26a90e 100644\n> > --- a/dir.c\n> > +++ b/dir.c\n> > @@ -2144,7 +2144,7 @@ static enum path_treatment\n> > treat_path_fast(struct dir_struct *dir,\n> > /*\n> > * We get path_recurse in the first run when\n> > * directory_exists_in_index() returns index_nonexistent. We\n> > - * are sure that new changes in the index does not impact the\n> > + * are sure that new changes in the index does not affect the\n> > * outcome. Return now.\n> > */\n> > return path_recurse;\n> > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> > index d0e0e019ea..1fcb98443c 100755\n> > --- a/t/perf/p5550-fetch-tags.sh\n> > +++ b/t/perf/p5550-fetch-tags.sh\n> > @@ -8,7 +8,7 @@ follows.\n> >\n> > The parent repository has a large number of tags which are disconnected from\n> > the rest of history. That makes them candidates for tag-following, but we never\n> > -actually grab them (and thus they will impact each subsequent fetch).\n> > +actually grab them (and thus they will affect each subsequent fetch).\n> >\n> > The child repository is a clone of parent, without the tags, and is at least\n> > one commit behind the parent (meaning that we will fetch one object and then\n> > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> > index a594b4aa7d..95daba4000 100755\n> > --- a/t/t0008-ignores.sh\n> > +++ b/t/t0008-ignores.sh\n> > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> > # test standard ignores\n> >\n> > # First make sure that the presence of a file in the working tree\n> > -# does not impact results, but that the presence of a file in the\n> > +# does not affect results, but that the presence of a file in the\n> > # index does unless the --no-index option is used.\n> >\n> > for subdir in '' 'a/'\n> > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> > index f028fd1418..a9348f655a 100755\n> > --- a/t/t0303-credential-external.sh\n> > +++ b/t/t0303-credential-external.sh\n> > @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> > eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> >\n> > # clean before the test in case there is cruft left\n> > -# over from a previous run that would impact results\n> > +# over from a previous run that would affect results\n> > helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> >\n> > helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> > index bc46713a43..568c258c5a 100755\n> > --- a/t/t2020-checkout-detach.sh\n> > +++ b/t/t2020-checkout-detach.sh\n> > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> > no SHA-1 ellipsis when not as\n> >\n> > You are in 'detached HEAD' state. You can look around, make experimental\n> > changes and commit them, and you can discard any commits you make in this\n> > - state without impacting any branches by switching back to a branch.\n> > + state without affecting any branches by switching back to a branch.\n> >\n> > If you want to create a new branch to retain commits you create, you may\n> > do so (now or later) by using -c with the switch command. Example:\n> > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> > print SHA-1 ellipsis when asked\n> >\n> > You are in 'detached HEAD' state. You can look around, make experimental\n> > changes and commit them, and you can discard any commits you make in this\n> > - state without impacting any branches by switching back to a branch.\n> > + state without affecting any branches by switching back to a branch.\n> >\n> > If you want to create a new branch to retain commits you create, you may\n> > do so (now or later) by using -c with the switch command. Example:\n> > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> > index 6cca8b84a6..97365a7786 100755\n> > --- a/t/t4013-diff-various.sh\n> > +++ b/t/t4013-diff-various.sh\n> > @@ -109,7 +109,7 @@ test_expect_success setup '\n> > git checkout -f master &&\n> >\n> > # Same merge as master, but with parents reversed. Hide it in a\n> > - # pseudo-ref to avoid impacting tests with --all.\n> > + # pseudo-ref to avoid affecting tests with --all.\n> > commit=$(echo reverse |\n> > git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> > git update-ref REVERSE $commit &&\n> > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> > index 7204799a0b..33a6efce2f 100755\n> > --- a/t/t5000-tar-tree.sh\n> > +++ b/t/t5000-tar-tree.sh\n> > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> > # Pull the size and date of each entry in a tarfile using the system tar.\n> > #\n> > # We'll pull out only the year from the date; that avoids any question of\n> > -# timezones impacting the result (as long as we keep our test times away from a\n> > +# timezones affecting the result (as long as we keep our test times away from a\n> > # year boundary; our reference times are all in August).\n> > #\n> > # The output of tar_info is expected to be \" \", both in decimal. It\n> > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> > index 6348e8d733..ff65f86f50 100644\n> > --- a/t/test-lib-functions.sh\n> > +++ b/t/test-lib-functions.sh\n> > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> > }\n> >\n> > # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> > -# it also works for shell functions (though those functions cannot impact\n> > +# it also works for shell functions (though those functions cannot affect\n> > # the environment outside of the test_env invocation).\n> > test_env () {\n> > (\n> > --\n> > 2.17.1\n> >\n> >\n> > From varun Mon Apr 5 16:45:37 2021\n> > Return-Path: \n> > Received: (from varun@localhost)\n> > by black-diamond (8.15.2/8.15.2/Submit) id 135LjbIS027022;\n> > Mon, 5 Apr 2021 16:45:37 -0500\n> > From: Varun Varada \n> > To: git@vger.kernel.org\n> > Cc: Varun Varada \n> > Subject: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"\n> > Date: Mon, 5 Apr 2021 16:44:35 -0500\n> > Message-Id: <20210405214435.26979-1-varuncvarada@gmail.com>\n> > X-Mailer: git-send-email 2.17.1\n> >\n> > There are a bunch of places in the code/docs which use the word \"impact\"\n> > incorrectly. This is especially true of places where it says \"will not\n> > impact\", which suggests that it might have an effect, albeit not as\n> > strong of a one. This commit replaces all of these with their\n> > appropriate alternative so that the docs not only does not use jargon,\n> > but are also unambiguous.\n> >\n> > Signed-off-by: Varun Varada \n> > ---\n> > Documentation/MyFirstContribution.txt | 2 +-\n> > Documentation/MyFirstObjectWalk.txt | 2 +-\n> > Documentation/config/pack.txt | 2 +-\n> > Documentation/git-fast-import.txt | 14 +++++++-------\n> > Documentation/git-fetch.txt | 2 +-\n> > .../technical/hash-function-transition.txt | 2 +-\n> > Documentation/user-manual.txt | 4 ++--\n> > advice.c | 2 +-\n> > builtin/fast-import.c | 2 +-\n> > builtin/pack-objects.c | 2 +-\n> > compat/nedmalloc/malloc.c.h | 2 +-\n> > contrib/coccinelle/README | 2 +-\n> > dir.c | 2 +-\n> > t/perf/p5550-fetch-tags.sh | 2 +-\n> > t/t0008-ignores.sh | 2 +-\n> > t/t0303-credential-external.sh | 2 +-\n> > t/t2020-checkout-detach.sh | 4 ++--\n> > t/t4013-diff-various.sh | 2 +-\n> > t/t5000-tar-tree.sh | 2 +-\n> > t/test-lib-functions.sh | 2 +-\n> > 20 files changed, 28 insertions(+), 28 deletions(-)\n> >\n> > diff --git a/Documentation/MyFirstContribution.txt\n> > b/Documentation/MyFirstContribution.txt\n> > index af0a9da62e..8372a7e59e 100644\n> > --- a/Documentation/MyFirstContribution.txt\n> > +++ b/Documentation/MyFirstContribution.txt\n> > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> > how to show it in the general\n> > command list shown by `git help git` or `git help -a`, which is generated from\n> > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> > line above it in alphabetical order. Now, we can add some attributes about the\n> > -command which impacts where it shows up in the aforementioned help\n> > commands. The\n> > +command which affects where it shows up in the aforementioned help\n> > commands. The\n> > top of `command-list.txt` shares some information about what each attribute\n> > means; in those help pages, the commands are sorted according to these\n> > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> > diff --git a/Documentation/MyFirstObjectWalk.txt\n> > b/Documentation/MyFirstObjectWalk.txt\n> > index 2d10eea7a9..fd5bb8fb7d 100644\n> > --- a/Documentation/MyFirstObjectWalk.txt\n> > +++ b/Documentation/MyFirstObjectWalk.txt\n> > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> > By running your walk with and without the filter, you should find\n> > that the total\n> > object count in each case is identical. You can also time each invocation of\n> > the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> > -to yourself the runtime impact of tracking all omitted objects.\n> > +to yourself the runtime effect of tracking all omitted objects.\n> >\n> > === Changing the Order\n> >\n> > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> > index 3da4ea98e2..00fcc9d7c7 100644\n> > --- a/Documentation/config/pack.txt\n> > +++ b/Documentation/config/pack.txt\n> > @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> > This cache is used to speed up the writing object phase by not\n> > having to recompute the final delta result once the best match\n> > for all objects is found. Repacking large repositories on machines\n> > - which are tight with memory might be badly impacted by this though,\n> > + which are tight with memory might be badly affected by this though,\n> > especially if this cache pushes the system into swapping.\n> > A value of 0 means no limit. The smallest size of 1 byte may be\n> > used to virtually disable this cache. Defaults to 256 MiB.\n> > diff --git a/Documentation/git-fast-import.txt\n> > b/Documentation/git-fast-import.txt\n> > index 39cfa05b28..c6d8e4e1d7 100644\n> > --- a/Documentation/git-fast-import.txt\n> > +++ b/Documentation/git-fast-import.txt\n> > @@ -58,7 +58,7 @@ OPTIONS\n> > allowing fast-import to access the filesystem outside of the\n> > repository). These options are disabled by default, but can be\n> > allowed by providing this option on the command line. This\n> > - currently impacts only the `export-marks`, `import-marks`, and\n> > + currently affects only the `export-marks`, `import-marks`, and\n> > `import-marks-if-exists` feature commands.\n> > +\n> > Only enable this option if you trust the program generating the\n> > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> >\n> > A `filecopy` command takes effect immediately. Once the source\n> > location has been copied to the destination any future commands\n> > -applied to the source location will not impact the destination of\n> > +applied to the source location will not affect the destination of\n> > the copy.\n> >\n> > `filerename`\n> > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> > A `filerename` command takes effect immediately. Once the source\n> > location has been renamed to the destination any future commands\n> > applied to the source location will create new files there and not\n> > -impact the destination of the rename.\n> > +affect the destination of the rename.\n> >\n> > Note that a `filerename` is the same as a `filecopy` followed by a\n> > `filedelete` of the source location. There is a slight performance\n> > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> > to be required).\n> > ~~~~~~~~~~\n> > Causes fast-import to print the entire `progress` line unmodified to\n> > its standard output channel (file descriptor 1) when the command is\n> > -processed from the input stream. The command otherwise has no impact\n> > +processed from the input stream. The command otherwise has no effect\n> > on the current import, or on any of fast-import's internal state.\n> >\n> > ....\n> > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> > ~~~~~~~~~~\n> > Causes fast-import to print the SHA-1 corresponding to a mark to\n> > stdout or to the file descriptor previously arranged with the\n> > -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> > +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> > current import; its purpose is to retrieve SHA-1s that later commits\n> > might want to refer to in their commit messages.\n> >\n> > @@ -1050,7 +1050,7 @@ this output safely.\n> > ~~~~~~~~~~\n> > Causes fast-import to print a blob to a file descriptor previously\n> > arranged with the `--cat-blob-fd` argument. The command otherwise\n> > -has no impact on the current import; its main purpose is to\n> > +has no effect on the current import; its main purpose is to\n> > retrieve blobs that may be in fast-import's memory but not\n> > accessible from the target repository.\n> >\n> > @@ -1366,7 +1366,7 @@ code considerably.\n> >\n> > The branch LRU builtin to fast-import tends to behave very well, and the\n> > cost of activating an inactive branch is so low that bouncing around\n> > -between branches has virtually no impact on import performance.\n> > +between branches has virtually no effect on import performance.\n> >\n> > Handling Renames\n> > ~~~~~~~~~~~~~~~~\n> > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> > index 9067c2079e..01cf3b3d16 100644\n> > --- a/Documentation/git-fetch.txt\n> > +++ b/Documentation/git-fetch.txt\n> > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> > If left to accumulate, these stale references might make performance\n> > worse on big and busy repos that have a lot of branch churn, and\n> > e.g. make the output of commands like `git branch -a --contains\n> > -` needlessly verbose, as well as impacting anything else\n> > +` needlessly verbose, as well as affecting anything else\n> > that'll work with the complete set of known references.\n> >\n> > These remote-tracking references can be deleted as a one-off with\n> > diff --git a/Documentation/technical/hash-function-transition.txt\n> > b/Documentation/technical/hash-function-transition.txt\n> > index 7c1630bf83..f4296faffc 100644\n> > --- a/Documentation/technical/hash-function-transition.txt\n> > +++ b/Documentation/technical/hash-function-transition.txt\n> > @@ -42,7 +42,7 @@ mitigations.\n> >\n> > If SHA-1 and its variants were to be truly broken, Git's hash function\n> > could not be considered cryptographically secure any more. This would\n> > -impact the communication of hash values because we could not trust\n> > +affect the communication of hash values because we could not trust\n> > that a given hash value represented the known good version of content\n> > that the speaker intended.\n> >\n> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > index fd480b8645..33c60c49d7 100644\n> > --- a/Documentation/user-manual.txt\n> > +++ b/Documentation/user-manual.txt\n> > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> >\n> > You are in 'detached HEAD' state. You can look around, make experimental\n> > changes and commit them, and you can discard any commits you make in this\n> > -state without impacting any branches by performing another switch.\n> > +state without affecting any branches by performing another switch.\n> >\n> > If you want to create a new branch to retain commits you create, you may\n> > do so (now or later) by using -c with the switch command again. Example:\n> > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> > overwritten by the result of\n> > the merge when this combining is done cleanly, or overwritten by a\n> > half-merged results when this combining results in conflicts.\n> > Therefore, if you have uncommitted changes touching the same files as\n> > -the ones impacted by the merge, Git will refuse to proceed. Most of\n> > +the ones affected by the merge, Git will refuse to proceed. Most of\n> > the time, you will want to commit your changes before you can merge,\n> > and if you don't, then linkgit:git-stash[1] can take these changes\n> > away while you're doing the merge, and reapply them afterwards.\n> > diff --git a/advice.c b/advice.c\n> > index 164742305f..9cbbb824a9 100644\n> > --- a/advice.c\n> > +++ b/advice.c\n> > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> > \"\\n\"\n> > \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> > \"changes and commit them, and you can discard any commits you make in this\\n\"\n> > - \"state without impacting any branches by switching back to a branch.\\n\"\n> > + \"state without affecting any branches by switching back to a branch.\\n\"\n> > \"\\n\"\n> > \"If you want to create a new branch to retain commits you create, you may\\n\"\n> > \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> > diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> > index 3afa81cf9a..24f362d2f4 100644\n> > --- a/builtin/fast-import.c\n> > +++ b/builtin/fast-import.c\n> > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> > const char *prefix)\n> > * We don't parse most options until after we've seen the set of\n> > * \"feature\" lines at the start of the stream (which allows the command\n> > * line to override stream data). But we must do an early parse of any\n> > - * command-line options that impact how we interpret the feature lines.\n> > + * command-line options that affect how we interpret the feature lines.\n> > */\n> > for (i = 1; i < argc; i++) {\n> > const char *arg = argv[i];\n> > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> > index 525c2d8552..749bbca241 100644\n> > --- a/builtin/pack-objects.c\n> > +++ b/builtin/pack-objects.c\n> > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> > /*\n> > * Mark ourselves as active and see if the next step causes\n> > * us to cycle to another active object. It's important to do\n> > - * this _before_ we loop, because it impacts where we make the\n> > + * this _before_ we loop, because it affects where we make the\n> > * cut, and thus how our total_depth counter works.\n> > * E.g., We may see a partial loop like:\n> > *\n> > diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h\n> > index 814845d4b3..de13121d76 100644\n> > --- a/compat/nedmalloc/malloc.c.h\n> > +++ b/compat/nedmalloc/malloc.c.h\n> > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > #endif /* (FOOTERS && !INSECURE) */\n> >\n> >\n> > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > #if !INSECURE\n> > #if defined(__GNUC__) && __GNUC__ >= 3\n> > #define RTCHECK(e) __builtin_expect(e, 1)\n> > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> > index f0e80bd7f0..92979ec770 100644\n> > --- a/contrib/coccinelle/README\n> > +++ b/contrib/coccinelle/README\n> > @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> > are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> >\n> > This allows to expose plans of pending large scale refactorings without\n> > - impacting the bad pattern checks.\n> > + affecting the bad pattern checks.\n> > diff --git a/dir.c b/dir.c\n> > index 3474e67e8f..235e26a90e 100644\n> > --- a/dir.c\n> > +++ b/dir.c\n> > @@ -2144,7 +2144,7 @@ static enum path_treatment\n> > treat_path_fast(struct dir_struct *dir,\n> > /*\n> > * We get path_recurse in the first run when\n> > * directory_exists_in_index() returns index_nonexistent. We\n> > - * are sure that new changes in the index does not impact the\n> > + * are sure that new changes in the index does not affect the\n> > * outcome. Return now.\n> > */\n> > return path_recurse;\n> > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> > index d0e0e019ea..1fcb98443c 100755\n> > --- a/t/perf/p5550-fetch-tags.sh\n> > +++ b/t/perf/p5550-fetch-tags.sh\n> > @@ -8,7 +8,7 @@ follows.\n> >\n> > The parent repository has a large number of tags which are disconnected from\n> > the rest of history. That makes them candidates for tag-following, but we never\n> > -actually grab them (and thus they will impact each subsequent fetch).\n> > +actually grab them (and thus they will affect each subsequent fetch).\n> >\n> > The child repository is a clone of parent, without the tags, and is at least\n> > one commit behind the parent (meaning that we will fetch one object and then\n> > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> > index a594b4aa7d..95daba4000 100755\n> > --- a/t/t0008-ignores.sh\n> > +++ b/t/t0008-ignores.sh\n> > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> > # test standard ignores\n> >\n> > # First make sure that the presence of a file in the working tree\n> > -# does not impact results, but that the presence of a file in the\n> > +# does not affect results, but that the presence of a file in the\n> > # index does unless the --no-index option is used.\n> >\n> > for subdir in '' 'a/'\n> > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> > index f028fd1418..a9348f655a 100755\n> > --- a/t/t0303-credential-external.sh\n> > +++ b/t/t0303-credential-external.sh\n> > @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> > eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> >\n> > # clean before the test in case there is cruft left\n> > -# over from a previous run that would impact results\n> > +# over from a previous run that would affect results\n> > helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> >\n> > helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> > index bc46713a43..568c258c5a 100755\n> > --- a/t/t2020-checkout-detach.sh\n> > +++ b/t/t2020-checkout-detach.sh\n> > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> > no SHA-1 ellipsis when not as\n> >\n> > You are in 'detached HEAD' state. You can look around, make experimental\n> > changes and commit them, and you can discard any commits you make in this\n> > - state without impacting any branches by switching back to a branch.\n> > + state without affecting any branches by switching back to a branch.\n> >\n> > If you want to create a new branch to retain commits you create, you may\n> > do so (now or later) by using -c with the switch command. Example:\n> > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> > print SHA-1 ellipsis when asked\n> >\n> > You are in 'detached HEAD' state. You can look around, make experimental\n> > changes and commit them, and you can discard any commits you make in this\n> > - state without impacting any branches by switching back to a branch.\n> > + state without affecting any branches by switching back to a branch.\n> >\n> > If you want to create a new branch to retain commits you create, you may\n> > do so (now or later) by using -c with the switch command. Example:\n> > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> > index 6cca8b84a6..97365a7786 100755\n> > --- a/t/t4013-diff-various.sh\n> > +++ b/t/t4013-diff-various.sh\n> > @@ -109,7 +109,7 @@ test_expect_success setup '\n> > git checkout -f master &&\n> >\n> > # Same merge as master, but with parents reversed. Hide it in a\n> > - # pseudo-ref to avoid impacting tests with --all.\n> > + # pseudo-ref to avoid affecting tests with --all.\n> > commit=$(echo reverse |\n> > git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> > git update-ref REVERSE $commit &&\n> > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> > index 7204799a0b..33a6efce2f 100755\n> > --- a/t/t5000-tar-tree.sh\n> > +++ b/t/t5000-tar-tree.sh\n> > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> > # Pull the size and date of each entry in a tarfile using the system tar.\n> > #\n> > # We'll pull out only the year from the date; that avoids any question of\n> > -# timezones impacting the result (as long as we keep our test times away from a\n> > +# timezones affecting the result (as long as we keep our test times away from a\n> > # year boundary; our reference times are all in August).\n> > #\n> > # The output of tar_info is expected to be \" \", both in decimal. It\n> > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> > index 6348e8d733..ff65f86f50 100644\n> > --- a/t/test-lib-functions.sh\n> > +++ b/t/test-lib-functions.sh\n> > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> > }\n> >\n> > # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> > -# it also works for shell functions (though those functions cannot impact\n> > +# it also works for shell functions (though those functions cannot affect\n> > # the environment outside of the test_env invocation).\n> > test_env () {\n> > (\n> > --\n> > 2.17.1\n> >\n"},{"id":"421100","messageId":"YGzoX9OeWMKXpqtf@coredump.intra.peff.net","threadId":"55436","inReplyTo":"CAD2i4DDr3Ftk6RE8cA74iSsJTpC9nEb=Cqvr79pF51BpcWEnsA@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-04-06T23:01:51Z","receivedAt":"2021-04-06T23:01:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n\n> > while using \"will not impact\" in an incorrect or unclear way may be a\n> > problem the word \"impact\" in itself is not \"jargon\".\n> \n> The word means \"to have a strong or marked effect on\" (v.) and \"a\n> strong or market influence\" (n.) when used figuratively; it is not\n> synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> all of the entries you've cited. Using it as such is the incorrect\n> part, so those are the instances I've changed in the diff.\n\nEr, is that true? From Michal's definitions:\n\n> > From The Collaborative International Dictionary of English v.0.48 :\n> [...]\n> > 2. To affect or influence, especially in a significant or\n\nIt literally uses \"affect\" to define it. The \"especially significant\"\ndoes not apply to many, but I don't think that makes it necessarily\nwrong to use impact to mean \"affect\".\n\nLikewise:\n\n> > From WordNet (r) 3.0 (2006) :\n> [...]\n> > v 1: press or wedge together; pack together\n> > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > affect, impact, bear upon, bear on, touch on,\n> > touch]\n\nThat is likewise listing \"impact\" and \"affect\" as synonyms.\n\nI do agree the word is over-used in some forms of writing, but I don't\nfind anything at all confusing or wrong about the uses that you changed\nin your patch. I am a native speaker of English. I'm open to the\nargument that non-native speakers may be more confused by the word. But\nthis seems like mostly a style preference thing, and I'd generally\nprefer to leave the contributions and style of the original writers\nintact unless there is a good reason not to.\n\nSuch changes are doubly unwanted in cases like this:\n\n> --- a/compat/nedmalloc/malloc.c.h\n> +++ b/compat/nedmalloc/malloc.c.h\n> @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> #endif /* (FOOTERS && !INSECURE) */\n> \n> \n> -/* In gcc, use __builtin_expect to minimize impact of checks */\n> +/* In gcc, use __builtin_expect to minimize affect of checks */\n> #if !INSECURE\n> #if defined(__GNUC__) && __GNUC__ >= 3\n> #define RTCHECK(e) __builtin_expect(e, 1)\n\nwhere the text is imported from another project, and we'd prefer to stay\nas close to their version as possible (e.g., to avoid unnecessary\nconflicts when pulling in new versions).\n\nAlso, this one should be \"effect\" anyway, as it is a noun.\n\n-Peff\n"},{"id":"421104","messageId":"CAD2i4DDNZ+oOgtp8dcgqwUjtwaTYnNmg2E0oC88ZDW3LYMBiRw@mail.gmail.com","threadId":"55436","inReplyTo":"YGzoX9OeWMKXpqtf@coredump.intra.peff.net","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-04-07T00:06:03Z","receivedAt":"2021-04-07T00:06:20Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Tue, 6 Apr 2021 at 18:01, Jeff King wrote:\n>\n> On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n>\n> > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > problem the word \"impact\" in itself is not \"jargon\".\n> >\n> > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > strong or market influence\" (n.) when used figuratively; it is not\n> > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > all of the entries you've cited. Using it as such is the incorrect\n> > part, so those are the instances I've changed in the diff.\n>\n> Er, is that true? From Michal's definitions:\n>\n> > > From The Collaborative International Dictionary of English v.0.48 :\n> > [...]\n> > > 2. To affect or influence, especially in a significant or\n>\n> It literally uses \"affect\" to define it. The \"especially significant\"\n> does not apply to many, but I don't think that makes it necessarily\n> wrong to use impact to mean \"affect\".\n\nI was drawing attention to the \"especially significant\" bit and the\nlike being there in all the entries. I'm not sure about these\ndictionaries, but the definition is hyperbolic / violent / shocking in\nevery reputable dictionary out there: the Oxford English Dictionary,\nMerriam-Webster, and Collins.\n\n>\n> Likewise:\n>\n> > > From WordNet (r) 3.0 (2006) :\n> > [...]\n> > > v 1: press or wedge together; pack together\n> > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > affect, impact, bear upon, bear on, touch on,\n> > > touch]\n>\n> That is likewise listing \"impact\" and \"affect\" as synonyms.\n>\n> I do agree the word is over-used in some forms of writing, but I don't\n> find anything at all confusing or wrong about the uses that you changed\n> in your patch. I am a native speaker of English. I'm open to the\n> argument that non-native speakers may be more confused by the word. But\n> this seems like mostly a style preference thing, and I'd generally\n> prefer to leave the contributions and style of the original writers\n> intact unless there is a good reason not to.\n\nI am a native English speaker as well, and there were multiple places\nwhere I had to think twice about what the sentences mean. I agree with\nyour sentiment about leaving stylistic preferences intact, but this is\nactually a semantic one. And given that there is a perfectly good\nalternative that doesn't have this confusion / jargon status, I wanted\nto make the change to improve it, especially where it says that in the\noutput of the git command (`git checkout` when in detached HEAD mode).\n\n>\n> Such changes are doubly unwanted in cases like this:\n>\n> > --- a/compat/nedmalloc/malloc.c.h\n> > +++ b/compat/nedmalloc/malloc.c.h\n> > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > #endif /* (FOOTERS && !INSECURE) */\n> >\n> >\n> > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > #if !INSECURE\n> > #if defined(__GNUC__) && __GNUC__ >= 3\n> > #define RTCHECK(e) __builtin_expect(e, 1)\n>\n> where the text is imported from another project, and we'd prefer to stay\n> as close to their version as possible (e.g., to avoid unnecessary\n> conflicts when pulling in new versions).\n\nThat's fair; I wasn't aware that this was being pulled directly from\nanother project. I can change this back.\n\n>\n> Also, this one should be \"effect\" anyway, as it is a noun.\n\nThis seems to have slipped through, as I used a text search tool.\n\n>\n> -Peff\n"},{"id":"423163","messageId":"CAD2i4DCtqxziTy5TPjG+U8EGC+8daJGXjpVgxoJwp8__t8fqxQ@mail.gmail.com","threadId":"55436","inReplyTo":"CAD2i4DDNZ+oOgtp8dcgqwUjtwaTYnNmg2E0oC88ZDW3LYMBiRw@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-04-28T00:39:57Z","receivedAt":"2021-04-28T00:40:10Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"Here's the updated diff:\n\n Documentation/MyFirstContribution.txt | 2 +-\n Documentation/MyFirstObjectWalk.txt | 2 +-\n Documentation/config/pack.txt | 2 +-\n Documentation/git-fast-import.txt | 14 +++++++-------\n Documentation/git-fetch.txt | 2 +-\n .../technical/hash-function-transition.txt | 2 +-\n Documentation/user-manual.txt | 4 ++--\n advice.c | 2 +-\n builtin/fast-import.c | 2 +-\n builtin/pack-objects.c | 2 +-\n contrib/coccinelle/README | 2 +-\n dir.c | 2 +-\n t/perf/p5550-fetch-tags.sh | 2 +-\n t/t0008-ignores.sh | 2 +-\n t/t0303-credential-external.sh | 2 +-\n t/t2020-checkout-detach.sh | 4 ++--\n t/t4013-diff-various.sh | 2 +-\n t/t5000-tar-tree.sh | 2 +-\n t/test-lib-functions.sh | 2 +-\n 19 files changed, 27 insertions(+), 27 deletions(-)\n\ndiff --git a/Documentation/MyFirstContribution.txt\nb/Documentation/MyFirstContribution.txt\nindex af0a9da62e..8372a7e59e 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\nhow to show it in the general\n command list shown by `git help git` or `git help -a`, which is generated from\n `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n line above it in alphabetical order. Now, we can add some attributes about the\n-command which impacts where it shows up in the aforementioned help\ncommands. The\n+command which affects where it shows up in the aforementioned help\ncommands. The\n top of `command-list.txt` shares some information about what each attribute\n means; in those help pages, the commands are sorted according to these\n attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\ndiff --git a/Documentation/MyFirstObjectWalk.txt\nb/Documentation/MyFirstObjectWalk.txt\nindex 2d10eea7a9..fd5bb8fb7d 100644\n--- a/Documentation/MyFirstObjectWalk.txt\n+++ b/Documentation/MyFirstObjectWalk.txt\n@@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n By running your walk with and without the filter, you should find\nthat the total\n object count in each case is identical. You can also time each invocation of\n the `walken` subcommand, with and without `omitted` being passed in, to confirm\n-to yourself the runtime impact of tracking all omitted objects.\n+to yourself the runtime effect of tracking all omitted objects.\n\n === Changing the Order\n\ndiff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\nindex 3da4ea98e2..00fcc9d7c7 100644\n--- a/Documentation/config/pack.txt\n+++ b/Documentation/config/pack.txt\n@@ -55,7 +55,7 @@ pack.deltaCacheSize::\n This cache is used to speed up the writing object phase by not\n having to recompute the final delta result once the best match\n for all objects is found. Repacking large repositories on machines\n- which are tight with memory might be badly impacted by this though,\n+ which are tight with memory might be badly affected by this though,\n especially if this cache pushes the system into swapping.\n A value of 0 means no limit. The smallest size of 1 byte may be\n used to virtually disable this cache. Defaults to 256 MiB.\ndiff --git a/Documentation/git-fast-import.txt\nb/Documentation/git-fast-import.txt\nindex 39cfa05b28..c6d8e4e1d7 100644\n--- a/Documentation/git-fast-import.txt\n+++ b/Documentation/git-fast-import.txt\n@@ -58,7 +58,7 @@ OPTIONS\n allowing fast-import to access the filesystem outside of the\n repository). These options are disabled by default, but can be\n allowed by providing this option on the command line. This\n- currently impacts only the `export-marks`, `import-marks`, and\n+ currently affects only the `export-marks`, `import-marks`, and\n `import-marks-if-exists` feature commands.\n +\n Only enable this option if you trust the program generating the\n@@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n\n A `filecopy` command takes effect immediately. Once the source\n location has been copied to the destination any future commands\n-applied to the source location will not impact the destination of\n+applied to the source location will not affect the destination of\n the copy.\n\n `filerename`\n@@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n A `filerename` command takes effect immediately. Once the source\n location has been renamed to the destination any future commands\n applied to the source location will create new files there and not\n-impact the destination of the rename.\n+affect the destination of the rename.\n\n Note that a `filerename` is the same as a `filecopy` followed by a\n `filedelete` of the source location. There is a slight performance\n@@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\nto be required).\n ~~~~~~~~~~\n Causes fast-import to print the entire `progress` line unmodified to\n its standard output channel (file descriptor 1) when the command is\n-processed from the input stream. The command otherwise has no impact\n+processed from the input stream. The command otherwise has no effect\n on the current import, or on any of fast-import's internal state.\n\n ....\n@@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n ~~~~~~~~~~\n Causes fast-import to print the SHA-1 corresponding to a mark to\n stdout or to the file descriptor previously arranged with the\n-`--cat-blob-fd` argument. The command otherwise has no impact on the\n+`--cat-blob-fd` argument. The command otherwise has no effect on the\n current import; its purpose is to retrieve SHA-1s that later commits\n might want to refer to in their commit messages.\n\n@@ -1050,7 +1050,7 @@ this output safely.\n ~~~~~~~~~~\n Causes fast-import to print a blob to a file descriptor previously\n arranged with the `--cat-blob-fd` argument. The command otherwise\n-has no impact on the current import; its main purpose is to\n+has no effect on the current import; its main purpose is to\n retrieve blobs that may be in fast-import's memory but not\n accessible from the target repository.\n\n@@ -1366,7 +1366,7 @@ code considerably.\n\n The branch LRU builtin to fast-import tends to behave very well, and the\n cost of activating an inactive branch is so low that bouncing around\n-between branches has virtually no impact on import performance.\n+between branches has virtually no effect on import performance.\n\n Handling Renames\n ~~~~~~~~~~~~~~~~\ndiff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\nindex 9067c2079e..01cf3b3d16 100644\n--- a/Documentation/git-fetch.txt\n+++ b/Documentation/git-fetch.txt\n@@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n If left to accumulate, these stale references might make performance\n worse on big and busy repos that have a lot of branch churn, and\n e.g. make the output of commands like `git branch -a --contains\n-` needlessly verbose, as well as impacting anything else\n+` needlessly verbose, as well as affecting anything else\n that'll work with the complete set of known references.\n\n These remote-tracking references can be deleted as a one-off with\ndiff --git a/Documentation/technical/hash-function-transition.txt\nb/Documentation/technical/hash-function-transition.txt\nindex 7c1630bf83..f4296faffc 100644\n--- a/Documentation/technical/hash-function-transition.txt\n+++ b/Documentation/technical/hash-function-transition.txt\n@@ -42,7 +42,7 @@ mitigations.\n\n If SHA-1 and its variants were to be truly broken, Git's hash function\n could not be considered cryptographically secure any more. This would\n-impact the communication of hash values because we could not trust\n+affect the communication of hash values because we could not trust\n that a given hash value represented the known good version of content\n that the speaker intended.\n\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex fd480b8645..33c60c49d7 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n\n You are in 'detached HEAD' state. You can look around, make experimental\n changes and commit them, and you can discard any commits you make in this\n-state without impacting any branches by performing another switch.\n+state without affecting any branches by performing another switch.\n\n If you want to create a new branch to retain commits you create, you may\n do so (now or later) by using -c with the switch command again. Example:\n@@ -1189,7 +1189,7 @@ their histories forked. The work tree is\noverwritten by the result of\n the merge when this combining is done cleanly, or overwritten by a\n half-merged results when this combining results in conflicts.\n Therefore, if you have uncommitted changes touching the same files as\n-the ones impacted by the merge, Git will refuse to proceed. Most of\n+the ones affected by the merge, Git will refuse to proceed. Most of\n the time, you will want to commit your changes before you can merge,\n and if you don't, then linkgit:git-stash[1] can take these changes\n away while you're doing the merge, and reapply them afterwards.\ndiff --git a/advice.c b/advice.c\nindex 164742305f..9cbbb824a9 100644\n--- a/advice.c\n+++ b/advice.c\n@@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n \"\\n\"\n \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n \"changes and commit them, and you can discard any commits you make in this\\n\"\n- \"state without impacting any branches by switching back to a branch.\\n\"\n+ \"state without affecting any branches by switching back to a branch.\\n\"\n \"\\n\"\n \"If you want to create a new branch to retain commits you create, you may\\n\"\n \"do so (now or later) by using -c with the switch command. Example:\\n\"\ndiff --git a/builtin/fast-import.c b/builtin/fast-import.c\nindex 3afa81cf9a..24f362d2f4 100644\n--- a/builtin/fast-import.c\n+++ b/builtin/fast-import.c\n@@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\nconst char *prefix)\n * We don't parse most options until after we've seen the set of\n * \"feature\" lines at the start of the stream (which allows the command\n * line to override stream data). But we must do an early parse of any\n- * command-line options that impact how we interpret the feature lines.\n+ * command-line options that affect how we interpret the feature lines.\n */\n for (i = 1; i < argc; i++) {\n const char *arg = argv[i];\ndiff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\nindex 525c2d8552..749bbca241 100644\n--- a/builtin/pack-objects.c\n+++ b/builtin/pack-objects.c\n@@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n /*\n * Mark ourselves as active and see if the next step causes\n * us to cycle to another active object. It's important to do\n- * this _before_ we loop, because it impacts where we make the\n+ * this _before_ we loop, because it affects where we make the\n * cut, and thus how our total_depth counter works.\n * E.g., We may see a partial loop like:\n *\ndiff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\nindex f0e80bd7f0..92979ec770 100644\n--- a/contrib/coccinelle/README\n+++ b/contrib/coccinelle/README\n@@ -40,4 +40,4 @@ There are two types of semantic patches:\n are ignored for checks, and can be applied using 'make coccicheck-pending'.\n\n This allows to expose plans of pending large scale refactorings without\n- impacting the bad pattern checks.\n+ affecting the bad pattern checks.\ndiff --git a/dir.c b/dir.c\nindex 3474e67e8f..235e26a90e 100644\n--- a/dir.c\n+++ b/dir.c\n@@ -2144,7 +2144,7 @@ static enum path_treatment\ntreat_path_fast(struct dir_struct *dir,\n /*\n * We get path_recurse in the first run when\n * directory_exists_in_index() returns index_nonexistent. We\n- * are sure that new changes in the index does not impact the\n+ * are sure that new changes in the index does not affect the\n * outcome. Return now.\n */\n return path_recurse;\ndiff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\nindex d0e0e019ea..1fcb98443c 100755\n--- a/t/perf/p5550-fetch-tags.sh\n+++ b/t/perf/p5550-fetch-tags.sh\n@@ -8,7 +8,7 @@ follows.\n\n The parent repository has a large number of tags which are disconnected from\n the rest of history. That makes them candidates for tag-following, but we never\n-actually grab them (and thus they will impact each subsequent fetch).\n+actually grab them (and thus they will affect each subsequent fetch).\n\n The child repository is a clone of parent, without the tags, and is at least\n one commit behind the parent (meaning that we will fetch one object and then\ndiff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\nindex a594b4aa7d..95daba4000 100755\n--- a/t/t0008-ignores.sh\n+++ b/t/t0008-ignores.sh\n@@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n # test standard ignores\n\n # First make sure that the presence of a file in the working tree\n-# does not impact results, but that the presence of a file in the\n+# does not affect results, but that the presence of a file in the\n # index does unless the --no-index option is used.\n\n for subdir in '' 'a/'\ndiff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\nindex f028fd1418..a9348f655a 100755\n--- a/t/t0303-credential-external.sh\n+++ b/t/t0303-credential-external.sh\n@@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n\n # clean before the test in case there is cruft left\n-# over from a previous run that would impact results\n+# over from a previous run that would affect results\n helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n\n helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\ndiff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\nindex bc46713a43..568c258c5a 100755\n--- a/t/t2020-checkout-detach.sh\n+++ b/t/t2020-checkout-detach.sh\n@@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\nno SHA-1 ellipsis when not as\n\n You are in 'detached HEAD' state. You can look around, make experimental\n changes and commit them, and you can discard any commits you make in this\n- state without impacting any branches by switching back to a branch.\n+ state without affecting any branches by switching back to a branch.\n\n If you want to create a new branch to retain commits you create, you may\n do so (now or later) by using -c with the switch command. Example:\n@@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\nprint SHA-1 ellipsis when asked\n\n You are in 'detached HEAD' state. You can look around, make experimental\n changes and commit them, and you can discard any commits you make in this\n- state without impacting any branches by switching back to a branch.\n+ state without affecting any branches by switching back to a branch.\n\n If you want to create a new branch to retain commits you create, you may\n do so (now or later) by using -c with the switch command. Example:\ndiff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\nindex 6cca8b84a6..97365a7786 100755\n--- a/t/t4013-diff-various.sh\n+++ b/t/t4013-diff-various.sh\n@@ -109,7 +109,7 @@ test_expect_success setup '\n git checkout -f master &&\n\n # Same merge as master, but with parents reversed. Hide it in a\n- # pseudo-ref to avoid impacting tests with --all.\n+ # pseudo-ref to avoid affecting tests with --all.\n commit=$(echo reverse |\n git commit-tree -p master^2 -p master^1 master^{tree}) &&\n git update-ref REVERSE $commit &&\ndiff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\nindex 7204799a0b..33a6efce2f 100755\n--- a/t/t5000-tar-tree.sh\n+++ b/t/t5000-tar-tree.sh\n@@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n # Pull the size and date of each entry in a tarfile using the system tar.\n #\n # We'll pull out only the year from the date; that avoids any question of\n-# timezones impacting the result (as long as we keep our test times away from a\n+# timezones affecting the result (as long as we keep our test times away from a\n # year boundary; our reference times are all in August).\n #\n # The output of tar_info is expected to be \" \", both in decimal. It\ndiff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\nindex 6348e8d733..ff65f86f50 100644\n--- a/t/test-lib-functions.sh\n+++ b/t/test-lib-functions.sh\n@@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n }\n\n # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n-# it also works for shell functions (though those functions cannot impact\n+# it also works for shell functions (though those functions cannot affect\n # the environment outside of the test_env invocation).\n test_env () {\n (\n-- \n2.17.1\n\nOn Tue, 6 Apr 2021 at 19:06, Varun Varada wrote:\n>\n> On Tue, 6 Apr 2021 at 18:01, Jeff King wrote:\n> >\n> > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n> >\n> > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > problem the word \"impact\" in itself is not \"jargon\".\n> > >\n> > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > strong or market influence\" (n.) when used figuratively; it is not\n> > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > all of the entries you've cited. Using it as such is the incorrect\n> > > part, so those are the instances I've changed in the diff.\n> >\n> > Er, is that true? From Michal's definitions:\n> >\n> > > > From The Collaborative International Dictionary of English v.0.48 :\n> > > [...]\n> > > > 2. To affect or influence, especially in a significant or\n> >\n> > It literally uses \"affect\" to define it. The \"especially significant\"\n> > does not apply to many, but I don't think that makes it necessarily\n> > wrong to use impact to mean \"affect\".\n>\n> I was drawing attention to the \"especially significant\" bit and the\n> like being there in all the entries. I'm not sure about these\n> dictionaries, but the definition is hyperbolic / violent / shocking in\n> every reputable dictionary out there: the Oxford English Dictionary,\n> Merriam-Webster, and Collins.\n>\n> >\n> > Likewise:\n> >\n> > > > From WordNet (r) 3.0 (2006) :\n> > > [...]\n> > > > v 1: press or wedge together; pack together\n> > > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > > affect, impact, bear upon, bear on, touch on,\n> > > > touch]\n> >\n> > That is likewise listing \"impact\" and \"affect\" as synonyms.\n> >\n> > I do agree the word is over-used in some forms of writing, but I don't\n> > find anything at all confusing or wrong about the uses that you changed\n> > in your patch. I am a native speaker of English. I'm open to the\n> > argument that non-native speakers may be more confused by the word. But\n> > this seems like mostly a style preference thing, and I'd generally\n> > prefer to leave the contributions and style of the original writers\n> > intact unless there is a good reason not to.\n>\n> I am a native English speaker as well, and there were multiple places\n> where I had to think twice about what the sentences mean. I agree with\n> your sentiment about leaving stylistic preferences intact, but this is\n> actually a semantic one. And given that there is a perfectly good\n> alternative that doesn't have this confusion / jargon status, I wanted\n> to make the change to improve it, especially where it says that in the\n> output of the git command (`git checkout` when in detached HEAD mode).\n>\n> >\n> > Such changes are doubly unwanted in cases like this:\n> >\n> > > --- a/compat/nedmalloc/malloc.c.h\n> > > +++ b/compat/nedmalloc/malloc.c.h\n> > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > > #endif /* (FOOTERS && !INSECURE) */\n> > >\n> > >\n> > > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > > #if !INSECURE\n> > > #if defined(__GNUC__) && __GNUC__ >= 3\n> > > #define RTCHECK(e) __builtin_expect(e, 1)\n> >\n> > where the text is imported from another project, and we'd prefer to stay\n> > as close to their version as possible (e.g., to avoid unnecessary\n> > conflicts when pulling in new versions).\n>\n> That's fair; I wasn't aware that this was being pulled directly from\n> another project. I can change this back.\n>\n> >\n> > Also, this one should be \"effect\" anyway, as it is a noun.\n>\n> This seems to have slipped through, as I used a text search tool.\n>\n> >\n> > -Peff\n"},{"id":"423188","messageId":"20210428085838.GN6564@kitsune.suse.cz","threadId":"55436","inReplyTo":"CAD2i4DCtqxziTy5TPjG+U8EGC+8daJGXjpVgxoJwp8__t8fqxQ@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-04-28T08:58:38Z","receivedAt":"2021-04-28T08:58:42Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:\n> Here's the updated diff:\n\nAs already said multiple general purpose dictionaries recognize '(have)\nstrong effect' as the meaning of 'impact', in some cases even the most\ncommon meaning.\n\nIn case you have some issue with the word 'jargon' Merriam-Webster gives\nthis definition:\n\n1: the technical terminology or characteristic idiom of a special activity or group\n2: obscure and often pretentious language marked by circumlocutions and long words\n3a: confused unintelligible language\nb: a strange, outlandish, or barbarous language or dialect\nc: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech\n\nwhich the word 'impact' does not fulfill.\n\nFurther, you would rarely discuss and document an effect that is\nnegligible so in vast majority of cases '(have) strong effect' (ie\n'impact') is synonymous to 'affect' and 'affect', respectively.\n\nIf you can pick out a few places where the use is specifically confusing\nthen please pick out those. Wholesale replacement of one word with\nanother synonym is not desired. It creates useless churn.\n\nYou could make a case that 'impact' is significantly less frequent word\ncompared to effect/affect and thus makes the text harder to understand\nfor non-native speakers. However, that's not the point you brought up,\nand even then it is very weak point to make, especially without any\nactual source for the frequency data. You could also counter that all of\nthese are common loanwords in many languages and are thus easy to\nunderstand to non-native speakers anyway.\n\nThanks\n\nMichal\n> \n> Documentation/MyFirstContribution.txt | 2 +-\n> Documentation/MyFirstObjectWalk.txt | 2 +-\n> Documentation/config/pack.txt | 2 +-\n> Documentation/git-fast-import.txt | 14 +++++++-------\n> Documentation/git-fetch.txt | 2 +-\n> .../technical/hash-function-transition.txt | 2 +-\n> Documentation/user-manual.txt | 4 ++--\n> advice.c | 2 +-\n> builtin/fast-import.c | 2 +-\n> builtin/pack-objects.c | 2 +-\n> contrib/coccinelle/README | 2 +-\n> dir.c | 2 +-\n> t/perf/p5550-fetch-tags.sh | 2 +-\n> t/t0008-ignores.sh | 2 +-\n> t/t0303-credential-external.sh | 2 +-\n> t/t2020-checkout-detach.sh | 4 ++--\n> t/t4013-diff-various.sh | 2 +-\n> t/t5000-tar-tree.sh | 2 +-\n> t/test-lib-functions.sh | 2 +-\n> 19 files changed, 27 insertions(+), 27 deletions(-)\n> \n> diff --git a/Documentation/MyFirstContribution.txt\n> b/Documentation/MyFirstContribution.txt\n> index af0a9da62e..8372a7e59e 100644\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> how to show it in the general\n> command list shown by `git help git` or `git help -a`, which is generated from\n> `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> line above it in alphabetical order. Now, we can add some attributes about the\n> -command which impacts where it shows up in the aforementioned help\n> commands. The\n> +command which affects where it shows up in the aforementioned help\n> commands. The\n> top of `command-list.txt` shares some information about what each attribute\n> means; in those help pages, the commands are sorted according to these\n> attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> diff --git a/Documentation/MyFirstObjectWalk.txt\n> b/Documentation/MyFirstObjectWalk.txt\n> index 2d10eea7a9..fd5bb8fb7d 100644\n> --- a/Documentation/MyFirstObjectWalk.txt\n> +++ b/Documentation/MyFirstObjectWalk.txt\n> @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> By running your walk with and without the filter, you should find\n> that the total\n> object count in each case is identical. You can also time each invocation of\n> the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> -to yourself the runtime impact of tracking all omitted objects.\n> +to yourself the runtime effect of tracking all omitted objects.\n> \n> === Changing the Order\n> \n> diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> index 3da4ea98e2..00fcc9d7c7 100644\n> --- a/Documentation/config/pack.txt\n> +++ b/Documentation/config/pack.txt\n> @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> This cache is used to speed up the writing object phase by not\n> having to recompute the final delta result once the best match\n> for all objects is found. Repacking large repositories on machines\n> - which are tight with memory might be badly impacted by this though,\n> + which are tight with memory might be badly affected by this though,\n> especially if this cache pushes the system into swapping.\n> A value of 0 means no limit. The smallest size of 1 byte may be\n> used to virtually disable this cache. Defaults to 256 MiB.\n> diff --git a/Documentation/git-fast-import.txt\n> b/Documentation/git-fast-import.txt\n> index 39cfa05b28..c6d8e4e1d7 100644\n> --- a/Documentation/git-fast-import.txt\n> +++ b/Documentation/git-fast-import.txt\n> @@ -58,7 +58,7 @@ OPTIONS\n> allowing fast-import to access the filesystem outside of the\n> repository). These options are disabled by default, but can be\n> allowed by providing this option on the command line. This\n> - currently impacts only the `export-marks`, `import-marks`, and\n> + currently affects only the `export-marks`, `import-marks`, and\n> `import-marks-if-exists` feature commands.\n> +\n> Only enable this option if you trust the program generating the\n> @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> \n> A `filecopy` command takes effect immediately. Once the source\n> location has been copied to the destination any future commands\n> -applied to the source location will not impact the destination of\n> +applied to the source location will not affect the destination of\n> the copy.\n> \n> `filerename`\n> @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> A `filerename` command takes effect immediately. Once the source\n> location has been renamed to the destination any future commands\n> applied to the source location will create new files there and not\n> -impact the destination of the rename.\n> +affect the destination of the rename.\n> \n> Note that a `filerename` is the same as a `filecopy` followed by a\n> `filedelete` of the source location. There is a slight performance\n> @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> to be required).\n> ~~~~~~~~~~\n> Causes fast-import to print the entire `progress` line unmodified to\n> its standard output channel (file descriptor 1) when the command is\n> -processed from the input stream. The command otherwise has no impact\n> +processed from the input stream. The command otherwise has no effect\n> on the current import, or on any of fast-import's internal state.\n> \n> ....\n> @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> ~~~~~~~~~~\n> Causes fast-import to print the SHA-1 corresponding to a mark to\n> stdout or to the file descriptor previously arranged with the\n> -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> current import; its purpose is to retrieve SHA-1s that later commits\n> might want to refer to in their commit messages.\n> \n> @@ -1050,7 +1050,7 @@ this output safely.\n> ~~~~~~~~~~\n> Causes fast-import to print a blob to a file descriptor previously\n> arranged with the `--cat-blob-fd` argument. The command otherwise\n> -has no impact on the current import; its main purpose is to\n> +has no effect on the current import; its main purpose is to\n> retrieve blobs that may be in fast-import's memory but not\n> accessible from the target repository.\n> \n> @@ -1366,7 +1366,7 @@ code considerably.\n> \n> The branch LRU builtin to fast-import tends to behave very well, and the\n> cost of activating an inactive branch is so low that bouncing around\n> -between branches has virtually no impact on import performance.\n> +between branches has virtually no effect on import performance.\n> \n> Handling Renames\n> ~~~~~~~~~~~~~~~~\n> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> index 9067c2079e..01cf3b3d16 100644\n> --- a/Documentation/git-fetch.txt\n> +++ b/Documentation/git-fetch.txt\n> @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> If left to accumulate, these stale references might make performance\n> worse on big and busy repos that have a lot of branch churn, and\n> e.g. make the output of commands like `git branch -a --contains\n> -` needlessly verbose, as well as impacting anything else\n> +` needlessly verbose, as well as affecting anything else\n> that'll work with the complete set of known references.\n> \n> These remote-tracking references can be deleted as a one-off with\n> diff --git a/Documentation/technical/hash-function-transition.txt\n> b/Documentation/technical/hash-function-transition.txt\n> index 7c1630bf83..f4296faffc 100644\n> --- a/Documentation/technical/hash-function-transition.txt\n> +++ b/Documentation/technical/hash-function-transition.txt\n> @@ -42,7 +42,7 @@ mitigations.\n> \n> If SHA-1 and its variants were to be truly broken, Git's hash function\n> could not be considered cryptographically secure any more. This would\n> -impact the communication of hash values because we could not trust\n> +affect the communication of hash values because we could not trust\n> that a given hash value represented the known good version of content\n> that the speaker intended.\n> \n> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> index fd480b8645..33c60c49d7 100644\n> --- a/Documentation/user-manual.txt\n> +++ b/Documentation/user-manual.txt\n> @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> \n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> -state without impacting any branches by performing another switch.\n> +state without affecting any branches by performing another switch.\n> \n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command again. Example:\n> @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> overwritten by the result of\n> the merge when this combining is done cleanly, or overwritten by a\n> half-merged results when this combining results in conflicts.\n> Therefore, if you have uncommitted changes touching the same files as\n> -the ones impacted by the merge, Git will refuse to proceed. Most of\n> +the ones affected by the merge, Git will refuse to proceed. Most of\n> the time, you will want to commit your changes before you can merge,\n> and if you don't, then linkgit:git-stash[1] can take these changes\n> away while you're doing the merge, and reapply them afterwards.\n> diff --git a/advice.c b/advice.c\n> index 164742305f..9cbbb824a9 100644\n> --- a/advice.c\n> +++ b/advice.c\n> @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> \"\\n\"\n> \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> \"changes and commit them, and you can discard any commits you make in this\\n\"\n> - \"state without impacting any branches by switching back to a branch.\\n\"\n> + \"state without affecting any branches by switching back to a branch.\\n\"\n> \"\\n\"\n> \"If you want to create a new branch to retain commits you create, you may\\n\"\n> \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> index 3afa81cf9a..24f362d2f4 100644\n> --- a/builtin/fast-import.c\n> +++ b/builtin/fast-import.c\n> @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> const char *prefix)\n> * We don't parse most options until after we've seen the set of\n> * \"feature\" lines at the start of the stream (which allows the command\n> * line to override stream data). But we must do an early parse of any\n> - * command-line options that impact how we interpret the feature lines.\n> + * command-line options that affect how we interpret the feature lines.\n> */\n> for (i = 1; i < argc; i++) {\n> const char *arg = argv[i];\n> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> index 525c2d8552..749bbca241 100644\n> --- a/builtin/pack-objects.c\n> +++ b/builtin/pack-objects.c\n> @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> /*\n> * Mark ourselves as active and see if the next step causes\n> * us to cycle to another active object. It's important to do\n> - * this _before_ we loop, because it impacts where we make the\n> + * this _before_ we loop, because it affects where we make the\n> * cut, and thus how our total_depth counter works.\n> * E.g., We may see a partial loop like:\n> *\n> diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> index f0e80bd7f0..92979ec770 100644\n> --- a/contrib/coccinelle/README\n> +++ b/contrib/coccinelle/README\n> @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> \n> This allows to expose plans of pending large scale refactorings without\n> - impacting the bad pattern checks.\n> + affecting the bad pattern checks.\n> diff --git a/dir.c b/dir.c\n> index 3474e67e8f..235e26a90e 100644\n> --- a/dir.c\n> +++ b/dir.c\n> @@ -2144,7 +2144,7 @@ static enum path_treatment\n> treat_path_fast(struct dir_struct *dir,\n> /*\n> * We get path_recurse in the first run when\n> * directory_exists_in_index() returns index_nonexistent. We\n> - * are sure that new changes in the index does not impact the\n> + * are sure that new changes in the index does not affect the\n> * outcome. Return now.\n> */\n> return path_recurse;\n> diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> index d0e0e019ea..1fcb98443c 100755\n> --- a/t/perf/p5550-fetch-tags.sh\n> +++ b/t/perf/p5550-fetch-tags.sh\n> @@ -8,7 +8,7 @@ follows.\n> \n> The parent repository has a large number of tags which are disconnected from\n> the rest of history. That makes them candidates for tag-following, but we never\n> -actually grab them (and thus they will impact each subsequent fetch).\n> +actually grab them (and thus they will affect each subsequent fetch).\n> \n> The child repository is a clone of parent, without the tags, and is at least\n> one commit behind the parent (meaning that we will fetch one object and then\n> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> index a594b4aa7d..95daba4000 100755\n> --- a/t/t0008-ignores.sh\n> +++ b/t/t0008-ignores.sh\n> @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> # test standard ignores\n> \n> # First make sure that the presence of a file in the working tree\n> -# does not impact results, but that the presence of a file in the\n> +# does not affect results, but that the presence of a file in the\n> # index does unless the --no-index option is used.\n> \n> for subdir in '' 'a/'\n> diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> index f028fd1418..a9348f655a 100755\n> --- a/t/t0303-credential-external.sh\n> +++ b/t/t0303-credential-external.sh\n> @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> \n> # clean before the test in case there is cruft left\n> -# over from a previous run that would impact results\n> +# over from a previous run that would affect results\n> helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> \n> helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> index bc46713a43..568c258c5a 100755\n> --- a/t/t2020-checkout-detach.sh\n> +++ b/t/t2020-checkout-detach.sh\n> @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> no SHA-1 ellipsis when not as\n> \n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> - state without impacting any branches by switching back to a branch.\n> + state without affecting any branches by switching back to a branch.\n> \n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command. Example:\n> @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> print SHA-1 ellipsis when asked\n> \n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> - state without impacting any branches by switching back to a branch.\n> + state without affecting any branches by switching back to a branch.\n> \n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command. Example:\n> diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> index 6cca8b84a6..97365a7786 100755\n> --- a/t/t4013-diff-various.sh\n> +++ b/t/t4013-diff-various.sh\n> @@ -109,7 +109,7 @@ test_expect_success setup '\n> git checkout -f master &&\n> \n> # Same merge as master, but with parents reversed. Hide it in a\n> - # pseudo-ref to avoid impacting tests with --all.\n> + # pseudo-ref to avoid affecting tests with --all.\n> commit=$(echo reverse |\n> git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> git update-ref REVERSE $commit &&\n> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> index 7204799a0b..33a6efce2f 100755\n> --- a/t/t5000-tar-tree.sh\n> +++ b/t/t5000-tar-tree.sh\n> @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> # Pull the size and date of each entry in a tarfile using the system tar.\n> #\n> # We'll pull out only the year from the date; that avoids any question of\n> -# timezones impacting the result (as long as we keep our test times away from a\n> +# timezones affecting the result (as long as we keep our test times away from a\n> # year boundary; our reference times are all in August).\n> #\n> # The output of tar_info is expected to be \" \", both in decimal. It\n> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> index 6348e8d733..ff65f86f50 100644\n> --- a/t/test-lib-functions.sh\n> +++ b/t/test-lib-functions.sh\n> @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> }\n> \n> # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> -# it also works for shell functions (though those functions cannot impact\n> +# it also works for shell functions (though those functions cannot affect\n> # the environment outside of the test_env invocation).\n> test_env () {\n> (\n> -- \n> 2.17.1\n> \n> On Tue, 6 Apr 2021 at 19:06, Varun Varada wrote:\n> >\n> > On Tue, 6 Apr 2021 at 18:01, Jeff King wrote:\n> > >\n> > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n> > >\n> > > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > > problem the word \"impact\" in itself is not \"jargon\".\n> > > >\n> > > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > > strong or market influence\" (n.) when used figuratively; it is not\n> > > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > > all of the entries you've cited. Using it as such is the incorrect\n> > > > part, so those are the instances I've changed in the diff.\n> > >\n> > > Er, is that true? From Michal's definitions:\n> > >\n> > > > > From The Collaborative International Dictionary of English v.0.48 :\n> > > > [...]\n> > > > > 2. To affect or influence, especially in a significant or\n> > >\n> > > It literally uses \"affect\" to define it. The \"especially significant\"\n> > > does not apply to many, but I don't think that makes it necessarily\n> > > wrong to use impact to mean \"affect\".\n> >\n> > I was drawing attention to the \"especially significant\" bit and the\n> > like being there in all the entries. I'm not sure about these\n> > dictionaries, but the definition is hyperbolic / violent / shocking in\n> > every reputable dictionary out there: the Oxford English Dictionary,\n> > Merriam-Webster, and Collins.\n> >\n> > >\n> > > Likewise:\n> > >\n> > > > > From WordNet (r) 3.0 (2006) :\n> > > > [...]\n> > > > > v 1: press or wedge together; pack together\n> > > > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > > > affect, impact, bear upon, bear on, touch on,\n> > > > > touch]\n> > >\n> > > That is likewise listing \"impact\" and \"affect\" as synonyms.\n> > >\n> > > I do agree the word is over-used in some forms of writing, but I don't\n> > > find anything at all confusing or wrong about the uses that you changed\n> > > in your patch. I am a native speaker of English. I'm open to the\n> > > argument that non-native speakers may be more confused by the word. But\n> > > this seems like mostly a style preference thing, and I'd generally\n> > > prefer to leave the contributions and style of the original writers\n> > > intact unless there is a good reason not to.\n> >\n> > I am a native English speaker as well, and there were multiple places\n> > where I had to think twice about what the sentences mean. I agree with\n> > your sentiment about leaving stylistic preferences intact, but this is\n> > actually a semantic one. And given that there is a perfectly good\n> > alternative that doesn't have this confusion / jargon status, I wanted\n> > to make the change to improve it, especially where it says that in the\n> > output of the git command (`git checkout` when in detached HEAD mode).\n> >\n> > >\n> > > Such changes are doubly unwanted in cases like this:\n> > >\n> > > > --- a/compat/nedmalloc/malloc.c.h\n> > > > +++ b/compat/nedmalloc/malloc.c.h\n> > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > > > #endif /* (FOOTERS && !INSECURE) */\n> > > >\n> > > >\n> > > > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > > > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > > > #if !INSECURE\n> > > > #if defined(__GNUC__) && __GNUC__ >= 3\n> > > > #define RTCHECK(e) __builtin_expect(e, 1)\n> > >\n> > > where the text is imported from another project, and we'd prefer to stay\n> > > as close to their version as possible (e.g., to avoid unnecessary\n> > > conflicts when pulling in new versions).\n> >\n> > That's fair; I wasn't aware that this was being pulled directly from\n> > another project. I can change this back.\n> >\n> > >\n> > > Also, this one should be \"effect\" anyway, as it is a noun.\n> >\n> > This seems to have slipped through, as I used a text search tool.\n> >\n> > >\n> > > -Peff\n"},{"id":"423208","messageId":"CAD2i4DASL-ZAsLm=_U53zvqMaAC_AOsGnTe-H=XQsfnftgb=rA@mail.gmail.com","threadId":"55436","inReplyTo":"20210428085838.GN6564@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-04-28T18:15:07Z","receivedAt":"2021-04-28T18:15:21Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Wed, 28 Apr 2021 at 03:58, Michal Suchánek wrote:\n>\n> On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:\n> > Here's the updated diff:\n>\n> As already said multiple general purpose dictionaries recognize '(have)\n> strong effect' as the meaning of 'impact', in some cases even the most\n> common meaning.\n\nThere's no contention here. That's the meaning I've been referring to as well.\n\n>\n> In case you have some issue with the word 'jargon' Merriam-Webster gives\n> this definition:\n>\n> 1: the technical terminology or characteristic idiom of a special activity or group\n> 2: obscure and often pretentious language marked by circumlocutions and long words\n> 3a: confused unintelligible language\n> b: a strange, outlandish, or barbarous language or dialect\n> c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech\n>\n> which the word 'impact' does not fulfill.\n>\n> Further, you would rarely discuss and document an effect that is\n> negligible so in vast majority of cases '(have) strong effect' (ie\n> 'impact') is synonymous to 'affect' and 'affect', respectively.\n\nThis is not true, especially in technical contexts. \"Affect\" doesn't\nmean \"has a slight effect on\", but simply \"has an effect on\". This\nsuffices in most cases. In cases where one would like to highlight the\noverwhelming/awesome/debilitating/marked/strong effect that something\nhas, \"impact\" can be used. To say that every effect is overwhelming or\nstrong is jargon.\n\n>\n> If you can pick out a few places where the use is specifically confusing\n> then please pick out those. Wholesale replacement of one word with\n> another synonym is not desired. It creates useless churn.\n\nI've actually not done a wholesale replacement blindly; the ones I\nreplaced are the places where I couldn't find any case where it is\nreferring to a \"strong/marked effect\". This is especially true in the\nnegative constructions. If you could help me find places where you\nthink the intended meaning is indeed \"a strong/marked effect\", I can\nremove those from the changes.\n\n>\n> You could make a case that 'impact' is significantly less frequent word\n> compared to effect/affect and thus makes the text harder to understand\n> for non-native speakers. However, that's not the point you brought up,\n> and even then it is very weak point to make, especially without any\n> actual source for the frequency data. You could also counter that all of\n> these are common loanwords in many languages and are thus easy to\n> understand to non-native speakers anyway.\n>\n> Thanks\n>\n> Michal\n> >\n> > Documentation/MyFirstContribution.txt | 2 +-\n> > Documentation/MyFirstObjectWalk.txt | 2 +-\n> > Documentation/config/pack.txt | 2 +-\n> > Documentation/git-fast-import.txt | 14 +++++++-------\n> > Documentation/git-fetch.txt | 2 +-\n> > .../technical/hash-function-transition.txt | 2 +-\n> > Documentation/user-manual.txt | 4 ++--\n> > advice.c | 2 +-\n> > builtin/fast-import.c | 2 +-\n> > builtin/pack-objects.c | 2 +-\n> > contrib/coccinelle/README | 2 +-\n> > dir.c | 2 +-\n> > t/perf/p5550-fetch-tags.sh | 2 +-\n> > t/t0008-ignores.sh | 2 +-\n> > t/t0303-credential-external.sh | 2 +-\n> > t/t2020-checkout-detach.sh | 4 ++--\n> > t/t4013-diff-various.sh | 2 +-\n> > t/t5000-tar-tree.sh | 2 +-\n> > t/test-lib-functions.sh | 2 +-\n> > 19 files changed, 27 insertions(+), 27 deletions(-)\n> >\n> > diff --git a/Documentation/MyFirstContribution.txt\n> > b/Documentation/MyFirstContribution.txt\n> > index af0a9da62e..8372a7e59e 100644\n> > --- a/Documentation/MyFirstContribution.txt\n> > +++ b/Documentation/MyFirstContribution.txt\n> > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> > how to show it in the general\n> > command list shown by `git help git` or `git help -a`, which is generated from\n> > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> > line above it in alphabetical order. Now, we can add some attributes about the\n> > -command which impacts where it shows up in the aforementioned help\n> > commands. The\n> > +command which affects where it shows up in the aforementioned help\n> > commands. The\n> > top of `command-list.txt` shares some information about what each attribute\n> > means; in those help pages, the commands are sorted according to these\n> > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> > diff --git a/Documentation/MyFirstObjectWalk.txt\n> > b/Documentation/MyFirstObjectWalk.txt\n> > index 2d10eea7a9..fd5bb8fb7d 100644\n> > --- a/Documentation/MyFirstObjectWalk.txt\n> > +++ b/Documentation/MyFirstObjectWalk.txt\n> > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> > By running your walk with and without the filter, you should find\n> > that the total\n> > object count in each case is identical. You can also time each invocation of\n> > the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> > -to yourself the runtime impact of tracking all omitted objects.\n> > +to yourself the runtime effect of tracking all omitted objects.\n> >\n> > === Changing the Order\n> >\n> > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> > index 3da4ea98e2..00fcc9d7c7 100644\n> > --- a/Documentation/config/pack.txt\n> > +++ b/Documentation/config/pack.txt\n> > @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> > This cache is used to speed up the writing object phase by not\n> > having to recompute the final delta result once the best match\n> > for all objects is found. Repacking large repositories on machines\n> > - which are tight with memory might be badly impacted by this though,\n> > + which are tight with memory might be badly affected by this though,\n> > especially if this cache pushes the system into swapping.\n> > A value of 0 means no limit. The smallest size of 1 byte may be\n> > used to virtually disable this cache. Defaults to 256 MiB.\n> > diff --git a/Documentation/git-fast-import.txt\n> > b/Documentation/git-fast-import.txt\n> > index 39cfa05b28..c6d8e4e1d7 100644\n> > --- a/Documentation/git-fast-import.txt\n> > +++ b/Documentation/git-fast-import.txt\n> > @@ -58,7 +58,7 @@ OPTIONS\n> > allowing fast-import to access the filesystem outside of the\n> > repository). These options are disabled by default, but can be\n> > allowed by providing this option on the command line. This\n> > - currently impacts only the `export-marks`, `import-marks`, and\n> > + currently affects only the `export-marks`, `import-marks`, and\n> > `import-marks-if-exists` feature commands.\n> > +\n> > Only enable this option if you trust the program generating the\n> > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> >\n> > A `filecopy` command takes effect immediately. Once the source\n> > location has been copied to the destination any future commands\n> > -applied to the source location will not impact the destination of\n> > +applied to the source location will not affect the destination of\n> > the copy.\n> >\n> > `filerename`\n> > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> > A `filerename` command takes effect immediately. Once the source\n> > location has been renamed to the destination any future commands\n> > applied to the source location will create new files there and not\n> > -impact the destination of the rename.\n> > +affect the destination of the rename.\n> >\n> > Note that a `filerename` is the same as a `filecopy` followed by a\n> > `filedelete` of the source location. There is a slight performance\n> > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> > to be required).\n> > ~~~~~~~~~~\n> > Causes fast-import to print the entire `progress` line unmodified to\n> > its standard output channel (file descriptor 1) when the command is\n> > -processed from the input stream. The command otherwise has no impact\n> > +processed from the input stream. The command otherwise has no effect\n> > on the current import, or on any of fast-import's internal state.\n> >\n> > ....\n> > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> > ~~~~~~~~~~\n> > Causes fast-import to print the SHA-1 corresponding to a mark to\n> > stdout or to the file descriptor previously arranged with the\n> > -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> > +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> > current import; its purpose is to retrieve SHA-1s that later commits\n> > might want to refer to in their commit messages.\n> >\n> > @@ -1050,7 +1050,7 @@ this output safely.\n> > ~~~~~~~~~~\n> > Causes fast-import to print a blob to a file descriptor previously\n> > arranged with the `--cat-blob-fd` argument. The command otherwise\n> > -has no impact on the current import; its main purpose is to\n> > +has no effect on the current import; its main purpose is to\n> > retrieve blobs that may be in fast-import's memory but not\n> > accessible from the target repository.\n> >\n> > @@ -1366,7 +1366,7 @@ code considerably.\n> >\n> > The branch LRU builtin to fast-import tends to behave very well, and the\n> > cost of activating an inactive branch is so low that bouncing around\n> > -between branches has virtually no impact on import performance.\n> > +between branches has virtually no effect on import performance.\n> >\n> > Handling Renames\n> > ~~~~~~~~~~~~~~~~\n> > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> > index 9067c2079e..01cf3b3d16 100644\n> > --- a/Documentation/git-fetch.txt\n> > +++ b/Documentation/git-fetch.txt\n> > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> > If left to accumulate, these stale references might make performance\n> > worse on big and busy repos that have a lot of branch churn, and\n> > e.g. make the output of commands like `git branch -a --contains\n> > -` needlessly verbose, as well as impacting anything else\n> > +` needlessly verbose, as well as affecting anything else\n> > that'll work with the complete set of known references.\n> >\n> > These remote-tracking references can be deleted as a one-off with\n> > diff --git a/Documentation/technical/hash-function-transition.txt\n> > b/Documentation/technical/hash-function-transition.txt\n> > index 7c1630bf83..f4296faffc 100644\n> > --- a/Documentation/technical/hash-function-transition.txt\n> > +++ b/Documentation/technical/hash-function-transition.txt\n> > @@ -42,7 +42,7 @@ mitigations.\n> >\n> > If SHA-1 and its variants were to be truly broken, Git's hash function\n> > could not be considered cryptographically secure any more. This would\n> > -impact the communication of hash values because we could not trust\n> > +affect the communication of hash values because we could not trust\n> > that a given hash value represented the known good version of content\n> > that the speaker intended.\n> >\n> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > index fd480b8645..33c60c49d7 100644\n> > --- a/Documentation/user-manual.txt\n> > +++ b/Documentation/user-manual.txt\n> > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> >\n> > You are in 'detached HEAD' state. You can look around, make experimental\n> > changes and commit them, and you can discard any commits you make in this\n> > -state without impacting any branches by performing another switch.\n> > +state without affecting any branches by performing another switch.\n> >\n> > If you want to create a new branch to retain commits you create, you may\n> > do so (now or later) by using -c with the switch command again. Example:\n> > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> > overwritten by the result of\n> > the merge when this combining is done cleanly, or overwritten by a\n> > half-merged results when this combining results in conflicts.\n> > Therefore, if you have uncommitted changes touching the same files as\n> > -the ones impacted by the merge, Git will refuse to proceed. Most of\n> > +the ones affected by the merge, Git will refuse to proceed. Most of\n> > the time, you will want to commit your changes before you can merge,\n> > and if you don't, then linkgit:git-stash[1] can take these changes\n> > away while you're doing the merge, and reapply them afterwards.\n> > diff --git a/advice.c b/advice.c\n> > index 164742305f..9cbbb824a9 100644\n> > --- a/advice.c\n> > +++ b/advice.c\n> > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> > \"\\n\"\n> > \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> > \"changes and commit them, and you can discard any commits you make in this\\n\"\n> > - \"state without impacting any branches by switching back to a branch.\\n\"\n> > + \"state without affecting any branches by switching back to a branch.\\n\"\n> > \"\\n\"\n> > \"If you want to create a new branch to retain commits you create, you may\\n\"\n> > \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> > diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> > index 3afa81cf9a..24f362d2f4 100644\n> > --- a/builtin/fast-import.c\n> > +++ b/builtin/fast-import.c\n> > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> > const char *prefix)\n> > * We don't parse most options until after we've seen the set of\n> > * \"feature\" lines at the start of the stream (which allows the command\n> > * line to override stream data). But we must do an early parse of any\n> > - * command-line options that impact how we interpret the feature lines.\n> > + * command-line options that affect how we interpret the feature lines.\n> > */\n> > for (i = 1; i < argc; i++) {\n> > const char *arg = argv[i];\n> > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> > index 525c2d8552..749bbca241 100644\n> > --- a/builtin/pack-objects.c\n> > +++ b/builtin/pack-objects.c\n> > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> > /*\n> > * Mark ourselves as active and see if the next step causes\n> > * us to cycle to another active object. It's important to do\n> > - * this _before_ we loop, because it impacts where we make the\n> > + * this _before_ we loop, because it affects where we make the\n> > * cut, and thus how our total_depth counter works.\n> > * E.g., We may see a partial loop like:\n> > *\n> > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> > index f0e80bd7f0..92979ec770 100644\n> > --- a/contrib/coccinelle/README\n> > +++ b/contrib/coccinelle/README\n> > @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> > are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> >\n> > This allows to expose plans of pending large scale refactorings without\n> > - impacting the bad pattern checks.\n> > + affecting the bad pattern checks.\n> > diff --git a/dir.c b/dir.c\n> > index 3474e67e8f..235e26a90e 100644\n> > --- a/dir.c\n> > +++ b/dir.c\n> > @@ -2144,7 +2144,7 @@ static enum path_treatment\n> > treat_path_fast(struct dir_struct *dir,\n> > /*\n> > * We get path_recurse in the first run when\n> > * directory_exists_in_index() returns index_nonexistent. We\n> > - * are sure that new changes in the index does not impact the\n> > + * are sure that new changes in the index does not affect the\n> > * outcome. Return now.\n> > */\n> > return path_recurse;\n> > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> > index d0e0e019ea..1fcb98443c 100755\n> > --- a/t/perf/p5550-fetch-tags.sh\n> > +++ b/t/perf/p5550-fetch-tags.sh\n> > @@ -8,7 +8,7 @@ follows.\n> >\n> > The parent repository has a large number of tags which are disconnected from\n> > the rest of history. That makes them candidates for tag-following, but we never\n> > -actually grab them (and thus they will impact each subsequent fetch).\n> > +actually grab them (and thus they will affect each subsequent fetch).\n> >\n> > The child repository is a clone of parent, without the tags, and is at least\n> > one commit behind the parent (meaning that we will fetch one object and then\n> > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> > index a594b4aa7d..95daba4000 100755\n> > --- a/t/t0008-ignores.sh\n> > +++ b/t/t0008-ignores.sh\n> > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> > # test standard ignores\n> >\n> > # First make sure that the presence of a file in the working tree\n> > -# does not impact results, but that the presence of a file in the\n> > +# does not affect results, but that the presence of a file in the\n> > # index does unless the --no-index option is used.\n> >\n> > for subdir in '' 'a/'\n> > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> > index f028fd1418..a9348f655a 100755\n> > --- a/t/t0303-credential-external.sh\n> > +++ b/t/t0303-credential-external.sh\n> > @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> > eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> >\n> > # clean before the test in case there is cruft left\n> > -# over from a previous run that would impact results\n> > +# over from a previous run that would affect results\n> > helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> >\n> > helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> > index bc46713a43..568c258c5a 100755\n> > --- a/t/t2020-checkout-detach.sh\n> > +++ b/t/t2020-checkout-detach.sh\n> > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> > no SHA-1 ellipsis when not as\n> >\n> > You are in 'detached HEAD' state. You can look around, make experimental\n> > changes and commit them, and you can discard any commits you make in this\n> > - state without impacting any branches by switching back to a branch.\n> > + state without affecting any branches by switching back to a branch.\n> >\n> > If you want to create a new branch to retain commits you create, you may\n> > do so (now or later) by using -c with the switch command. Example:\n> > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> > print SHA-1 ellipsis when asked\n> >\n> > You are in 'detached HEAD' state. You can look around, make experimental\n> > changes and commit them, and you can discard any commits you make in this\n> > - state without impacting any branches by switching back to a branch.\n> > + state without affecting any branches by switching back to a branch.\n> >\n> > If you want to create a new branch to retain commits you create, you may\n> > do so (now or later) by using -c with the switch command. Example:\n> > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> > index 6cca8b84a6..97365a7786 100755\n> > --- a/t/t4013-diff-various.sh\n> > +++ b/t/t4013-diff-various.sh\n> > @@ -109,7 +109,7 @@ test_expect_success setup '\n> > git checkout -f master &&\n> >\n> > # Same merge as master, but with parents reversed. Hide it in a\n> > - # pseudo-ref to avoid impacting tests with --all.\n> > + # pseudo-ref to avoid affecting tests with --all.\n> > commit=$(echo reverse |\n> > git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> > git update-ref REVERSE $commit &&\n> > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> > index 7204799a0b..33a6efce2f 100755\n> > --- a/t/t5000-tar-tree.sh\n> > +++ b/t/t5000-tar-tree.sh\n> > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> > # Pull the size and date of each entry in a tarfile using the system tar.\n> > #\n> > # We'll pull out only the year from the date; that avoids any question of\n> > -# timezones impacting the result (as long as we keep our test times away from a\n> > +# timezones affecting the result (as long as we keep our test times away from a\n> > # year boundary; our reference times are all in August).\n> > #\n> > # The output of tar_info is expected to be \" \", both in decimal. It\n> > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> > index 6348e8d733..ff65f86f50 100644\n> > --- a/t/test-lib-functions.sh\n> > +++ b/t/test-lib-functions.sh\n> > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> > }\n> >\n> > # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> > -# it also works for shell functions (though those functions cannot impact\n> > +# it also works for shell functions (though those functions cannot affect\n> > # the environment outside of the test_env invocation).\n> > test_env () {\n> > (\n> > --\n> > 2.17.1\n> >\n> > On Tue, 6 Apr 2021 at 19:06, Varun Varada wrote:\n> > >\n> > > On Tue, 6 Apr 2021 at 18:01, Jeff King wrote:\n> > > >\n> > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n> > > >\n> > > > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > > > problem the word \"impact\" in itself is not \"jargon\".\n> > > > >\n> > > > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > > > strong or market influence\" (n.) when used figuratively; it is not\n> > > > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > > > all of the entries you've cited. Using it as such is the incorrect\n> > > > > part, so those are the instances I've changed in the diff.\n> > > >\n> > > > Er, is that true? From Michal's definitions:\n> > > >\n> > > > > > From The Collaborative International Dictionary of English v.0.48 :\n> > > > > [...]\n> > > > > > 2. To affect or influence, especially in a significant or\n> > > >\n> > > > It literally uses \"affect\" to define it. The \"especially significant\"\n> > > > does not apply to many, but I don't think that makes it necessarily\n> > > > wrong to use impact to mean \"affect\".\n> > >\n> > > I was drawing attention to the \"especially significant\" bit and the\n> > > like being there in all the entries. I'm not sure about these\n> > > dictionaries, but the definition is hyperbolic / violent / shocking in\n> > > every reputable dictionary out there: the Oxford English Dictionary,\n> > > Merriam-Webster, and Collins.\n> > >\n> > > >\n> > > > Likewise:\n> > > >\n> > > > > > From WordNet (r) 3.0 (2006) :\n> > > > > [...]\n> > > > > > v 1: press or wedge together; pack together\n> > > > > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > > > > affect, impact, bear upon, bear on, touch on,\n> > > > > > touch]\n> > > >\n> > > > That is likewise listing \"impact\" and \"affect\" as synonyms.\n> > > >\n> > > > I do agree the word is over-used in some forms of writing, but I don't\n> > > > find anything at all confusing or wrong about the uses that you changed\n> > > > in your patch. I am a native speaker of English. I'm open to the\n> > > > argument that non-native speakers may be more confused by the word. But\n> > > > this seems like mostly a style preference thing, and I'd generally\n> > > > prefer to leave the contributions and style of the original writers\n> > > > intact unless there is a good reason not to.\n> > >\n> > > I am a native English speaker as well, and there were multiple places\n> > > where I had to think twice about what the sentences mean. I agree with\n> > > your sentiment about leaving stylistic preferences intact, but this is\n> > > actually a semantic one. And given that there is a perfectly good\n> > > alternative that doesn't have this confusion / jargon status, I wanted\n> > > to make the change to improve it, especially where it says that in the\n> > > output of the git command (`git checkout` when in detached HEAD mode).\n> > >\n> > > >\n> > > > Such changes are doubly unwanted in cases like this:\n> > > >\n> > > > > --- a/compat/nedmalloc/malloc.c.h\n> > > > > +++ b/compat/nedmalloc/malloc.c.h\n> > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > > > > #endif /* (FOOTERS && !INSECURE) */\n> > > > >\n> > > > >\n> > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > > > > #if !INSECURE\n> > > > > #if defined(__GNUC__) && __GNUC__ >= 3\n> > > > > #define RTCHECK(e) __builtin_expect(e, 1)\n> > > >\n> > > > where the text is imported from another project, and we'd prefer to stay\n> > > > as close to their version as possible (e.g., to avoid unnecessary\n> > > > conflicts when pulling in new versions).\n> > >\n> > > That's fair; I wasn't aware that this was being pulled directly from\n> > > another project. I can change this back.\n> > >\n> > > >\n> > > > Also, this one should be \"effect\" anyway, as it is a noun.\n> > >\n> > > This seems to have slipped through, as I used a text search tool.\n> > >\n> > > >\n> > > > -Peff\n"},{"id":"423212","messageId":"20210428184956.GS6564@kitsune.suse.cz","threadId":"55436","inReplyTo":"CAD2i4DASL-ZAsLm=_U53zvqMaAC_AOsGnTe-H=XQsfnftgb=rA@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-04-28T18:49:57Z","receivedAt":"2021-04-28T18:50:01Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:\n> On Wed, 28 Apr 2021 at 03:58, Michal Suchánek wrote:\n> >\n> > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:\n> > > Here's the updated diff:\n> >\n> > As already said multiple general purpose dictionaries recognize '(have)\n> > strong effect' as the meaning of 'impact', in some cases even the most\n> > common meaning.\n> \n> There's no contention here. That's the meaning I've been referring to as well.\n> \n> >\n> > In case you have some issue with the word 'jargon' Merriam-Webster gives\n> > this definition:\n> >\n> > 1: the technical terminology or characteristic idiom of a special activity or group\n> > 2: obscure and often pretentious language marked by circumlocutions and long words\n> > 3a: confused unintelligible language\n> > b: a strange, outlandish, or barbarous language or dialect\n> > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech\n> >\n> > which the word 'impact' does not fulfill.\n> >\n> > Further, you would rarely discuss and document an effect that is\n> > negligible so in vast majority of cases '(have) strong effect' (ie\n> > 'impact') is synonymous to 'affect' and 'affect', respectively.\n> \n> This is not true, especially in technical contexts. \"Affect\" doesn't\n> mean \"has a slight effect on\", but simply \"has an effect on\". This\n> suffices in most cases. In cases where one would like to highlight the\n> overwhelming/awesome/debilitating/marked/strong effect that something\n> has, \"impact\" can be used. To say that every effect is overwhelming or\n> strong is jargon.\n> \n> >\n> > If you can pick out a few places where the use is specifically confusing\n> > then please pick out those. Wholesale replacement of one word with\n> > another synonym is not desired. It creates useless churn.\n> \n> I've actually not done a wholesale replacement blindly; the ones I\n> replaced are the places where I couldn't find any case where it is\n> referring to a \"strong/marked effect\". This is especially true in the\n> negative constructions. If you could help me find places where you\n> think the intended meaning is indeed \"a strong/marked effect\", I can\n> remove those from the changes.\n\nAs already pointed out before the mere fact that the author of the text\nbothered to document the effect ipmlies that the effect is strong/marked\nunless stated otherwise. At any rate 'strong' is always relative. Unless\nyou have a specific reference of average strenth anything can be\nconsidered strong or weak depending on point of view.\n\n> \n> >\n> > You could make a case that 'impact' is significantly less frequent word\n> > compared to effect/affect and thus makes the text harder to understand\n> > for non-native speakers. However, that's not the point you brought up,\n> > and even then it is very weak point to make, especially without any\n> > actual source for the frequency data. You could also counter that all of\n> > these are common loanwords in many languages and are thus easy to\n> > understand to non-native speakers anyway.\n> >\n> > Thanks\n> >\n> > Michal\n> > >\n> > > Documentation/MyFirstContribution.txt | 2 +-\n> > > Documentation/MyFirstObjectWalk.txt | 2 +-\n> > > Documentation/config/pack.txt | 2 +-\n> > > Documentation/git-fast-import.txt | 14 +++++++-------\n> > > Documentation/git-fetch.txt | 2 +-\n> > > .../technical/hash-function-transition.txt | 2 +-\n> > > Documentation/user-manual.txt | 4 ++--\n> > > advice.c | 2 +-\n> > > builtin/fast-import.c | 2 +-\n> > > builtin/pack-objects.c | 2 +-\n> > > contrib/coccinelle/README | 2 +-\n> > > dir.c | 2 +-\n> > > t/perf/p5550-fetch-tags.sh | 2 +-\n> > > t/t0008-ignores.sh | 2 +-\n> > > t/t0303-credential-external.sh | 2 +-\n> > > t/t2020-checkout-detach.sh | 4 ++--\n> > > t/t4013-diff-various.sh | 2 +-\n> > > t/t5000-tar-tree.sh | 2 +-\n> > > t/test-lib-functions.sh | 2 +-\n> > > 19 files changed, 27 insertions(+), 27 deletions(-)\n> > >\n> > > diff --git a/Documentation/MyFirstContribution.txt\n> > > b/Documentation/MyFirstContribution.txt\n> > > index af0a9da62e..8372a7e59e 100644\n> > > --- a/Documentation/MyFirstContribution.txt\n> > > +++ b/Documentation/MyFirstContribution.txt\n> > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> > > how to show it in the general\n> > > command list shown by `git help git` or `git help -a`, which is generated from\n> > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> > > line above it in alphabetical order. Now, we can add some attributes about the\n> > > -command which impacts where it shows up in the aforementioned help\n> > > commands. The\n> > > +command which affects where it shows up in the aforementioned help\n> > > commands. The\n> > > top of `command-list.txt` shares some information about what each attribute\n> > > means; in those help pages, the commands are sorted according to these\n> > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> > > diff --git a/Documentation/MyFirstObjectWalk.txt\n> > > b/Documentation/MyFirstObjectWalk.txt\n> > > index 2d10eea7a9..fd5bb8fb7d 100644\n> > > --- a/Documentation/MyFirstObjectWalk.txt\n> > > +++ b/Documentation/MyFirstObjectWalk.txt\n> > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> > > By running your walk with and without the filter, you should find\n> > > that the total\n> > > object count in each case is identical. You can also time each invocation of\n> > > the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> > > -to yourself the runtime impact of tracking all omitted objects.\n> > > +to yourself the runtime effect of tracking all omitted objects.\n> > >\n> > > === Changing the Order\n> > >\n> > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> > > index 3da4ea98e2..00fcc9d7c7 100644\n> > > --- a/Documentation/config/pack.txt\n> > > +++ b/Documentation/config/pack.txt\n> > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> > > This cache is used to speed up the writing object phase by not\n> > > having to recompute the final delta result once the best match\n> > > for all objects is found. Repacking large repositories on machines\n> > > - which are tight with memory might be badly impacted by this though,\n> > > + which are tight with memory might be badly affected by this though,\n> > > especially if this cache pushes the system into swapping.\n> > > A value of 0 means no limit. The smallest size of 1 byte may be\n> > > used to virtually disable this cache. Defaults to 256 MiB.\n> > > diff --git a/Documentation/git-fast-import.txt\n> > > b/Documentation/git-fast-import.txt\n> > > index 39cfa05b28..c6d8e4e1d7 100644\n> > > --- a/Documentation/git-fast-import.txt\n> > > +++ b/Documentation/git-fast-import.txt\n> > > @@ -58,7 +58,7 @@ OPTIONS\n> > > allowing fast-import to access the filesystem outside of the\n> > > repository). These options are disabled by default, but can be\n> > > allowed by providing this option on the command line. This\n> > > - currently impacts only the `export-marks`, `import-marks`, and\n> > > + currently affects only the `export-marks`, `import-marks`, and\n> > > `import-marks-if-exists` feature commands.\n> > > +\n> > > Only enable this option if you trust the program generating the\n> > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> > >\n> > > A `filecopy` command takes effect immediately. Once the source\n> > > location has been copied to the destination any future commands\n> > > -applied to the source location will not impact the destination of\n> > > +applied to the source location will not affect the destination of\n> > > the copy.\n> > >\n> > > `filerename`\n> > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> > > A `filerename` command takes effect immediately. Once the source\n> > > location has been renamed to the destination any future commands\n> > > applied to the source location will create new files there and not\n> > > -impact the destination of the rename.\n> > > +affect the destination of the rename.\n> > >\n> > > Note that a `filerename` is the same as a `filecopy` followed by a\n> > > `filedelete` of the source location. There is a slight performance\n> > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> > > to be required).\n> > > ~~~~~~~~~~\n> > > Causes fast-import to print the entire `progress` line unmodified to\n> > > its standard output channel (file descriptor 1) when the command is\n> > > -processed from the input stream. The command otherwise has no impact\n> > > +processed from the input stream. The command otherwise has no effect\n> > > on the current import, or on any of fast-import's internal state.\n> > >\n> > > ....\n> > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> > > ~~~~~~~~~~\n> > > Causes fast-import to print the SHA-1 corresponding to a mark to\n> > > stdout or to the file descriptor previously arranged with the\n> > > -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> > > +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> > > current import; its purpose is to retrieve SHA-1s that later commits\n> > > might want to refer to in their commit messages.\n> > >\n> > > @@ -1050,7 +1050,7 @@ this output safely.\n> > > ~~~~~~~~~~\n> > > Causes fast-import to print a blob to a file descriptor previously\n> > > arranged with the `--cat-blob-fd` argument. The command otherwise\n> > > -has no impact on the current import; its main purpose is to\n> > > +has no effect on the current import; its main purpose is to\n> > > retrieve blobs that may be in fast-import's memory but not\n> > > accessible from the target repository.\n> > >\n> > > @@ -1366,7 +1366,7 @@ code considerably.\n> > >\n> > > The branch LRU builtin to fast-import tends to behave very well, and the\n> > > cost of activating an inactive branch is so low that bouncing around\n> > > -between branches has virtually no impact on import performance.\n> > > +between branches has virtually no effect on import performance.\n> > >\n> > > Handling Renames\n> > > ~~~~~~~~~~~~~~~~\n> > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> > > index 9067c2079e..01cf3b3d16 100644\n> > > --- a/Documentation/git-fetch.txt\n> > > +++ b/Documentation/git-fetch.txt\n> > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> > > If left to accumulate, these stale references might make performance\n> > > worse on big and busy repos that have a lot of branch churn, and\n> > > e.g. make the output of commands like `git branch -a --contains\n> > > -` needlessly verbose, as well as impacting anything else\n> > > +` needlessly verbose, as well as affecting anything else\n> > > that'll work with the complete set of known references.\n> > >\n> > > These remote-tracking references can be deleted as a one-off with\n> > > diff --git a/Documentation/technical/hash-function-transition.txt\n> > > b/Documentation/technical/hash-function-transition.txt\n> > > index 7c1630bf83..f4296faffc 100644\n> > > --- a/Documentation/technical/hash-function-transition.txt\n> > > +++ b/Documentation/technical/hash-function-transition.txt\n> > > @@ -42,7 +42,7 @@ mitigations.\n> > >\n> > > If SHA-1 and its variants were to be truly broken, Git's hash function\n> > > could not be considered cryptographically secure any more. This would\n> > > -impact the communication of hash values because we could not trust\n> > > +affect the communication of hash values because we could not trust\n> > > that a given hash value represented the known good version of content\n> > > that the speaker intended.\n> > >\n> > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > > index fd480b8645..33c60c49d7 100644\n> > > --- a/Documentation/user-manual.txt\n> > > +++ b/Documentation/user-manual.txt\n> > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> > >\n> > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > changes and commit them, and you can discard any commits you make in this\n> > > -state without impacting any branches by performing another switch.\n> > > +state without affecting any branches by performing another switch.\n> > >\n> > > If you want to create a new branch to retain commits you create, you may\n> > > do so (now or later) by using -c with the switch command again. Example:\n> > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> > > overwritten by the result of\n> > > the merge when this combining is done cleanly, or overwritten by a\n> > > half-merged results when this combining results in conflicts.\n> > > Therefore, if you have uncommitted changes touching the same files as\n> > > -the ones impacted by the merge, Git will refuse to proceed. Most of\n> > > +the ones affected by the merge, Git will refuse to proceed. Most of\n> > > the time, you will want to commit your changes before you can merge,\n> > > and if you don't, then linkgit:git-stash[1] can take these changes\n> > > away while you're doing the merge, and reapply them afterwards.\n> > > diff --git a/advice.c b/advice.c\n> > > index 164742305f..9cbbb824a9 100644\n> > > --- a/advice.c\n> > > +++ b/advice.c\n> > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> > > \"\\n\"\n> > > \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> > > \"changes and commit them, and you can discard any commits you make in this\\n\"\n> > > - \"state without impacting any branches by switching back to a branch.\\n\"\n> > > + \"state without affecting any branches by switching back to a branch.\\n\"\n> > > \"\\n\"\n> > > \"If you want to create a new branch to retain commits you create, you may\\n\"\n> > > \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> > > diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> > > index 3afa81cf9a..24f362d2f4 100644\n> > > --- a/builtin/fast-import.c\n> > > +++ b/builtin/fast-import.c\n> > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> > > const char *prefix)\n> > > * We don't parse most options until after we've seen the set of\n> > > * \"feature\" lines at the start of the stream (which allows the command\n> > > * line to override stream data). But we must do an early parse of any\n> > > - * command-line options that impact how we interpret the feature lines.\n> > > + * command-line options that affect how we interpret the feature lines.\n> > > */\n> > > for (i = 1; i < argc; i++) {\n> > > const char *arg = argv[i];\n> > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> > > index 525c2d8552..749bbca241 100644\n> > > --- a/builtin/pack-objects.c\n> > > +++ b/builtin/pack-objects.c\n> > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> > > /*\n> > > * Mark ourselves as active and see if the next step causes\n> > > * us to cycle to another active object. It's important to do\n> > > - * this _before_ we loop, because it impacts where we make the\n> > > + * this _before_ we loop, because it affects where we make the\n> > > * cut, and thus how our total_depth counter works.\n> > > * E.g., We may see a partial loop like:\n> > > *\n> > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> > > index f0e80bd7f0..92979ec770 100644\n> > > --- a/contrib/coccinelle/README\n> > > +++ b/contrib/coccinelle/README\n> > > @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> > > are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> > >\n> > > This allows to expose plans of pending large scale refactorings without\n> > > - impacting the bad pattern checks.\n> > > + affecting the bad pattern checks.\n> > > diff --git a/dir.c b/dir.c\n> > > index 3474e67e8f..235e26a90e 100644\n> > > --- a/dir.c\n> > > +++ b/dir.c\n> > > @@ -2144,7 +2144,7 @@ static enum path_treatment\n> > > treat_path_fast(struct dir_struct *dir,\n> > > /*\n> > > * We get path_recurse in the first run when\n> > > * directory_exists_in_index() returns index_nonexistent. We\n> > > - * are sure that new changes in the index does not impact the\n> > > + * are sure that new changes in the index does not affect the\n> > > * outcome. Return now.\n> > > */\n> > > return path_recurse;\n> > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> > > index d0e0e019ea..1fcb98443c 100755\n> > > --- a/t/perf/p5550-fetch-tags.sh\n> > > +++ b/t/perf/p5550-fetch-tags.sh\n> > > @@ -8,7 +8,7 @@ follows.\n> > >\n> > > The parent repository has a large number of tags which are disconnected from\n> > > the rest of history. That makes them candidates for tag-following, but we never\n> > > -actually grab them (and thus they will impact each subsequent fetch).\n> > > +actually grab them (and thus they will affect each subsequent fetch).\n> > >\n> > > The child repository is a clone of parent, without the tags, and is at least\n> > > one commit behind the parent (meaning that we will fetch one object and then\n> > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> > > index a594b4aa7d..95daba4000 100755\n> > > --- a/t/t0008-ignores.sh\n> > > +++ b/t/t0008-ignores.sh\n> > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> > > # test standard ignores\n> > >\n> > > # First make sure that the presence of a file in the working tree\n> > > -# does not impact results, but that the presence of a file in the\n> > > +# does not affect results, but that the presence of a file in the\n> > > # index does unless the --no-index option is used.\n> > >\n> > > for subdir in '' 'a/'\n> > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> > > index f028fd1418..a9348f655a 100755\n> > > --- a/t/t0303-credential-external.sh\n> > > +++ b/t/t0303-credential-external.sh\n> > > @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> > > eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> > >\n> > > # clean before the test in case there is cruft left\n> > > -# over from a previous run that would impact results\n> > > +# over from a previous run that would affect results\n> > > helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > >\n> > > helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> > > index bc46713a43..568c258c5a 100755\n> > > --- a/t/t2020-checkout-detach.sh\n> > > +++ b/t/t2020-checkout-detach.sh\n> > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> > > no SHA-1 ellipsis when not as\n> > >\n> > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > changes and commit them, and you can discard any commits you make in this\n> > > - state without impacting any branches by switching back to a branch.\n> > > + state without affecting any branches by switching back to a branch.\n> > >\n> > > If you want to create a new branch to retain commits you create, you may\n> > > do so (now or later) by using -c with the switch command. Example:\n> > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> > > print SHA-1 ellipsis when asked\n> > >\n> > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > changes and commit them, and you can discard any commits you make in this\n> > > - state without impacting any branches by switching back to a branch.\n> > > + state without affecting any branches by switching back to a branch.\n> > >\n> > > If you want to create a new branch to retain commits you create, you may\n> > > do so (now or later) by using -c with the switch command. Example:\n> > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> > > index 6cca8b84a6..97365a7786 100755\n> > > --- a/t/t4013-diff-various.sh\n> > > +++ b/t/t4013-diff-various.sh\n> > > @@ -109,7 +109,7 @@ test_expect_success setup '\n> > > git checkout -f master &&\n> > >\n> > > # Same merge as master, but with parents reversed. Hide it in a\n> > > - # pseudo-ref to avoid impacting tests with --all.\n> > > + # pseudo-ref to avoid affecting tests with --all.\n> > > commit=$(echo reverse |\n> > > git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> > > git update-ref REVERSE $commit &&\n> > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> > > index 7204799a0b..33a6efce2f 100755\n> > > --- a/t/t5000-tar-tree.sh\n> > > +++ b/t/t5000-tar-tree.sh\n> > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> > > # Pull the size and date of each entry in a tarfile using the system tar.\n> > > #\n> > > # We'll pull out only the year from the date; that avoids any question of\n> > > -# timezones impacting the result (as long as we keep our test times away from a\n> > > +# timezones affecting the result (as long as we keep our test times away from a\n> > > # year boundary; our reference times are all in August).\n> > > #\n> > > # The output of tar_info is expected to be \" \", both in decimal. It\n> > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> > > index 6348e8d733..ff65f86f50 100644\n> > > --- a/t/test-lib-functions.sh\n> > > +++ b/t/test-lib-functions.sh\n> > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> > > }\n> > >\n> > > # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> > > -# it also works for shell functions (though those functions cannot impact\n> > > +# it also works for shell functions (though those functions cannot affect\n> > > # the environment outside of the test_env invocation).\n> > > test_env () {\n> > > (\n> > > --\n> > > 2.17.1\n> > >\n> > > On Tue, 6 Apr 2021 at 19:06, Varun Varada wrote:\n> > > >\n> > > > On Tue, 6 Apr 2021 at 18:01, Jeff King wrote:\n> > > > >\n> > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n> > > > >\n> > > > > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > > > > problem the word \"impact\" in itself is not \"jargon\".\n> > > > > >\n> > > > > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > > > > strong or market influence\" (n.) when used figuratively; it is not\n> > > > > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > > > > all of the entries you've cited. Using it as such is the incorrect\n> > > > > > part, so those are the instances I've changed in the diff.\n> > > > >\n> > > > > Er, is that true? From Michal's definitions:\n> > > > >\n> > > > > > > From The Collaborative International Dictionary of English v.0.48 :\n> > > > > > [...]\n> > > > > > > 2. To affect or influence, especially in a significant or\n> > > > >\n> > > > > It literally uses \"affect\" to define it. The \"especially significant\"\n> > > > > does not apply to many, but I don't think that makes it necessarily\n> > > > > wrong to use impact to mean \"affect\".\n> > > >\n> > > > I was drawing attention to the \"especially significant\" bit and the\n> > > > like being there in all the entries. I'm not sure about these\n> > > > dictionaries, but the definition is hyperbolic / violent / shocking in\n> > > > every reputable dictionary out there: the Oxford English Dictionary,\n> > > > Merriam-Webster, and Collins.\n> > > >\n> > > > >\n> > > > > Likewise:\n> > > > >\n> > > > > > > From WordNet (r) 3.0 (2006) :\n> > > > > > [...]\n> > > > > > > v 1: press or wedge together; pack together\n> > > > > > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > > > > > affect, impact, bear upon, bear on, touch on,\n> > > > > > > touch]\n> > > > >\n> > > > > That is likewise listing \"impact\" and \"affect\" as synonyms.\n> > > > >\n> > > > > I do agree the word is over-used in some forms of writing, but I don't\n> > > > > find anything at all confusing or wrong about the uses that you changed\n> > > > > in your patch. I am a native speaker of English. I'm open to the\n> > > > > argument that non-native speakers may be more confused by the word. But\n> > > > > this seems like mostly a style preference thing, and I'd generally\n> > > > > prefer to leave the contributions and style of the original writers\n> > > > > intact unless there is a good reason not to.\n> > > >\n> > > > I am a native English speaker as well, and there were multiple places\n> > > > where I had to think twice about what the sentences mean. I agree with\n> > > > your sentiment about leaving stylistic preferences intact, but this is\n> > > > actually a semantic one. And given that there is a perfectly good\n> > > > alternative that doesn't have this confusion / jargon status, I wanted\n> > > > to make the change to improve it, especially where it says that in the\n> > > > output of the git command (`git checkout` when in detached HEAD mode).\n> > > >\n> > > > >\n> > > > > Such changes are doubly unwanted in cases like this:\n> > > > >\n> > > > > > --- a/compat/nedmalloc/malloc.c.h\n> > > > > > +++ b/compat/nedmalloc/malloc.c.h\n> > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > > > > > #endif /* (FOOTERS && !INSECURE) */\n> > > > > >\n> > > > > >\n> > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > > > > > #if !INSECURE\n> > > > > > #if defined(__GNUC__) && __GNUC__ >= 3\n> > > > > > #define RTCHECK(e) __builtin_expect(e, 1)\n> > > > >\n> > > > > where the text is imported from another project, and we'd prefer to stay\n> > > > > as close to their version as possible (e.g., to avoid unnecessary\n> > > > > conflicts when pulling in new versions).\n> > > >\n> > > > That's fair; I wasn't aware that this was being pulled directly from\n> > > > another project. I can change this back.\n> > > >\n> > > > >\n> > > > > Also, this one should be \"effect\" anyway, as it is a noun.\n> > > >\n> > > > This seems to have slipped through, as I used a text search tool.\n> > > >\n> > > > >\n> > > > > -Peff\n"},{"id":"423311","messageId":"CAD2i4DCLpvAuwp5UEDcPA0wzr4Eg_qhs_xXDW1eLiOwYkUvL1g@mail.gmail.com","threadId":"55436","inReplyTo":"20210428184956.GS6564@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-04-30T01:51:07Z","receivedAt":"2021-04-30T01:51:23Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Wed, 28 Apr 2021 at 13:49, Michal Suchánek wrote:\n>\n> On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:\n> > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek wrote:\n> > >\n> > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:\n> > > > Here's the updated diff:\n> > >\n> > > As already said multiple general purpose dictionaries recognize '(have)\n> > > strong effect' as the meaning of 'impact', in some cases even the most\n> > > common meaning.\n> >\n> > There's no contention here. That's the meaning I've been referring to as well.\n> >\n> > >\n> > > In case you have some issue with the word 'jargon' Merriam-Webster gives\n> > > this definition:\n> > >\n> > > 1: the technical terminology or characteristic idiom of a special activity or group\n> > > 2: obscure and often pretentious language marked by circumlocutions and long words\n> > > 3a: confused unintelligible language\n> > > b: a strange, outlandish, or barbarous language or dialect\n> > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech\n> > >\n> > > which the word 'impact' does not fulfill.\n> > >\n> > > Further, you would rarely discuss and document an effect that is\n> > > negligible so in vast majority of cases '(have) strong effect' (ie\n> > > 'impact') is synonymous to 'affect' and 'affect', respectively.\n> >\n> > This is not true, especially in technical contexts. \"Affect\" doesn't\n> > mean \"has a slight effect on\", but simply \"has an effect on\". This\n> > suffices in most cases. In cases where one would like to highlight the\n> > overwhelming/awesome/debilitating/marked/strong effect that something\n> > has, \"impact\" can be used. To say that every effect is overwhelming or\n> > strong is jargon.\n> >\n> > >\n> > > If you can pick out a few places where the use is specifically confusing\n> > > then please pick out those. Wholesale replacement of one word with\n> > > another synonym is not desired. It creates useless churn.\n> >\n> > I've actually not done a wholesale replacement blindly; the ones I\n> > replaced are the places where I couldn't find any case where it is\n> > referring to a \"strong/marked effect\". This is especially true in the\n> > negative constructions. If you could help me find places where you\n> > think the intended meaning is indeed \"a strong/marked effect\", I can\n> > remove those from the changes.\n>\n> As already pointed out before the mere fact that the author of the text\n> bothered to document the effect ipmlies that the effect is strong/marked\n> unless stated otherwise. At any rate 'strong' is always relative. Unless\n> you have a specific reference of average strenth anything can be\n> considered strong or weak depending on point of view.\n\nThis doesn't seem like a plausible or strong argument given the\ncontext of the places where I'm editing the text. Most of them are\nnegative constructions, where if one were to assume \"strongly affect\"\nwas intended, then that raises the question of what actual effect it\nwill have. The only convincing example of this I can see is the one\nwhere it reads \"which are tight with memory might be badly impacted by\nthis though\". All of the other ones seem like they're binary in\nwhether they will have an effect at all or no, not graduated in terms\nof the degree of the effect it will have.\n\n>\n> >\n> > >\n> > > You could make a case that 'impact' is significantly less frequent word\n> > > compared to effect/affect and thus makes the text harder to understand\n> > > for non-native speakers. However, that's not the point you brought up,\n> > > and even then it is very weak point to make, especially without any\n> > > actual source for the frequency data. You could also counter that all of\n> > > these are common loanwords in many languages and are thus easy to\n> > > understand to non-native speakers anyway.\n> > >\n> > > Thanks\n> > >\n> > > Michal\n> > > >\n> > > > Documentation/MyFirstContribution.txt | 2 +-\n> > > > Documentation/MyFirstObjectWalk.txt | 2 +-\n> > > > Documentation/config/pack.txt | 2 +-\n> > > > Documentation/git-fast-import.txt | 14 +++++++-------\n> > > > Documentation/git-fetch.txt | 2 +-\n> > > > .../technical/hash-function-transition.txt | 2 +-\n> > > > Documentation/user-manual.txt | 4 ++--\n> > > > advice.c | 2 +-\n> > > > builtin/fast-import.c | 2 +-\n> > > > builtin/pack-objects.c | 2 +-\n> > > > contrib/coccinelle/README | 2 +-\n> > > > dir.c | 2 +-\n> > > > t/perf/p5550-fetch-tags.sh | 2 +-\n> > > > t/t0008-ignores.sh | 2 +-\n> > > > t/t0303-credential-external.sh | 2 +-\n> > > > t/t2020-checkout-detach.sh | 4 ++--\n> > > > t/t4013-diff-various.sh | 2 +-\n> > > > t/t5000-tar-tree.sh | 2 +-\n> > > > t/test-lib-functions.sh | 2 +-\n> > > > 19 files changed, 27 insertions(+), 27 deletions(-)\n> > > >\n> > > > diff --git a/Documentation/MyFirstContribution.txt\n> > > > b/Documentation/MyFirstContribution.txt\n> > > > index af0a9da62e..8372a7e59e 100644\n> > > > --- a/Documentation/MyFirstContribution.txt\n> > > > +++ b/Documentation/MyFirstContribution.txt\n> > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> > > > how to show it in the general\n> > > > command list shown by `git help git` or `git help -a`, which is generated from\n> > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> > > > line above it in alphabetical order. Now, we can add some attributes about the\n> > > > -command which impacts where it shows up in the aforementioned help\n> > > > commands. The\n> > > > +command which affects where it shows up in the aforementioned help\n> > > > commands. The\n> > > > top of `command-list.txt` shares some information about what each attribute\n> > > > means; in those help pages, the commands are sorted according to these\n> > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> > > > diff --git a/Documentation/MyFirstObjectWalk.txt\n> > > > b/Documentation/MyFirstObjectWalk.txt\n> > > > index 2d10eea7a9..fd5bb8fb7d 100644\n> > > > --- a/Documentation/MyFirstObjectWalk.txt\n> > > > +++ b/Documentation/MyFirstObjectWalk.txt\n> > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> > > > By running your walk with and without the filter, you should find\n> > > > that the total\n> > > > object count in each case is identical. You can also time each invocation of\n> > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> > > > -to yourself the runtime impact of tracking all omitted objects.\n> > > > +to yourself the runtime effect of tracking all omitted objects.\n> > > >\n> > > > === Changing the Order\n> > > >\n> > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> > > > index 3da4ea98e2..00fcc9d7c7 100644\n> > > > --- a/Documentation/config/pack.txt\n> > > > +++ b/Documentation/config/pack.txt\n> > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> > > > This cache is used to speed up the writing object phase by not\n> > > > having to recompute the final delta result once the best match\n> > > > for all objects is found. Repacking large repositories on machines\n> > > > - which are tight with memory might be badly impacted by this though,\n> > > > + which are tight with memory might be badly affected by this though,\n> > > > especially if this cache pushes the system into swapping.\n> > > > A value of 0 means no limit. The smallest size of 1 byte may be\n> > > > used to virtually disable this cache. Defaults to 256 MiB.\n> > > > diff --git a/Documentation/git-fast-import.txt\n> > > > b/Documentation/git-fast-import.txt\n> > > > index 39cfa05b28..c6d8e4e1d7 100644\n> > > > --- a/Documentation/git-fast-import.txt\n> > > > +++ b/Documentation/git-fast-import.txt\n> > > > @@ -58,7 +58,7 @@ OPTIONS\n> > > > allowing fast-import to access the filesystem outside of the\n> > > > repository). These options are disabled by default, but can be\n> > > > allowed by providing this option on the command line. This\n> > > > - currently impacts only the `export-marks`, `import-marks`, and\n> > > > + currently affects only the `export-marks`, `import-marks`, and\n> > > > `import-marks-if-exists` feature commands.\n> > > > +\n> > > > Only enable this option if you trust the program generating the\n> > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> > > >\n> > > > A `filecopy` command takes effect immediately. Once the source\n> > > > location has been copied to the destination any future commands\n> > > > -applied to the source location will not impact the destination of\n> > > > +applied to the source location will not affect the destination of\n> > > > the copy.\n> > > >\n> > > > `filerename`\n> > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> > > > A `filerename` command takes effect immediately. Once the source\n> > > > location has been renamed to the destination any future commands\n> > > > applied to the source location will create new files there and not\n> > > > -impact the destination of the rename.\n> > > > +affect the destination of the rename.\n> > > >\n> > > > Note that a `filerename` is the same as a `filecopy` followed by a\n> > > > `filedelete` of the source location. There is a slight performance\n> > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> > > > to be required).\n> > > > ~~~~~~~~~~\n> > > > Causes fast-import to print the entire `progress` line unmodified to\n> > > > its standard output channel (file descriptor 1) when the command is\n> > > > -processed from the input stream. The command otherwise has no impact\n> > > > +processed from the input stream. The command otherwise has no effect\n> > > > on the current import, or on any of fast-import's internal state.\n> > > >\n> > > > ....\n> > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> > > > ~~~~~~~~~~\n> > > > Causes fast-import to print the SHA-1 corresponding to a mark to\n> > > > stdout or to the file descriptor previously arranged with the\n> > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> > > > current import; its purpose is to retrieve SHA-1s that later commits\n> > > > might want to refer to in their commit messages.\n> > > >\n> > > > @@ -1050,7 +1050,7 @@ this output safely.\n> > > > ~~~~~~~~~~\n> > > > Causes fast-import to print a blob to a file descriptor previously\n> > > > arranged with the `--cat-blob-fd` argument. The command otherwise\n> > > > -has no impact on the current import; its main purpose is to\n> > > > +has no effect on the current import; its main purpose is to\n> > > > retrieve blobs that may be in fast-import's memory but not\n> > > > accessible from the target repository.\n> > > >\n> > > > @@ -1366,7 +1366,7 @@ code considerably.\n> > > >\n> > > > The branch LRU builtin to fast-import tends to behave very well, and the\n> > > > cost of activating an inactive branch is so low that bouncing around\n> > > > -between branches has virtually no impact on import performance.\n> > > > +between branches has virtually no effect on import performance.\n> > > >\n> > > > Handling Renames\n> > > > ~~~~~~~~~~~~~~~~\n> > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> > > > index 9067c2079e..01cf3b3d16 100644\n> > > > --- a/Documentation/git-fetch.txt\n> > > > +++ b/Documentation/git-fetch.txt\n> > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> > > > If left to accumulate, these stale references might make performance\n> > > > worse on big and busy repos that have a lot of branch churn, and\n> > > > e.g. make the output of commands like `git branch -a --contains\n> > > > -` needlessly verbose, as well as impacting anything else\n> > > > +` needlessly verbose, as well as affecting anything else\n> > > > that'll work with the complete set of known references.\n> > > >\n> > > > These remote-tracking references can be deleted as a one-off with\n> > > > diff --git a/Documentation/technical/hash-function-transition.txt\n> > > > b/Documentation/technical/hash-function-transition.txt\n> > > > index 7c1630bf83..f4296faffc 100644\n> > > > --- a/Documentation/technical/hash-function-transition.txt\n> > > > +++ b/Documentation/technical/hash-function-transition.txt\n> > > > @@ -42,7 +42,7 @@ mitigations.\n> > > >\n> > > > If SHA-1 and its variants were to be truly broken, Git's hash function\n> > > > could not be considered cryptographically secure any more. This would\n> > > > -impact the communication of hash values because we could not trust\n> > > > +affect the communication of hash values because we could not trust\n> > > > that a given hash value represented the known good version of content\n> > > > that the speaker intended.\n> > > >\n> > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > > > index fd480b8645..33c60c49d7 100644\n> > > > --- a/Documentation/user-manual.txt\n> > > > +++ b/Documentation/user-manual.txt\n> > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> > > >\n> > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > changes and commit them, and you can discard any commits you make in this\n> > > > -state without impacting any branches by performing another switch.\n> > > > +state without affecting any branches by performing another switch.\n> > > >\n> > > > If you want to create a new branch to retain commits you create, you may\n> > > > do so (now or later) by using -c with the switch command again. Example:\n> > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> > > > overwritten by the result of\n> > > > the merge when this combining is done cleanly, or overwritten by a\n> > > > half-merged results when this combining results in conflicts.\n> > > > Therefore, if you have uncommitted changes touching the same files as\n> > > > -the ones impacted by the merge, Git will refuse to proceed. Most of\n> > > > +the ones affected by the merge, Git will refuse to proceed. Most of\n> > > > the time, you will want to commit your changes before you can merge,\n> > > > and if you don't, then linkgit:git-stash[1] can take these changes\n> > > > away while you're doing the merge, and reapply them afterwards.\n> > > > diff --git a/advice.c b/advice.c\n> > > > index 164742305f..9cbbb824a9 100644\n> > > > --- a/advice.c\n> > > > +++ b/advice.c\n> > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> > > > \"\\n\"\n> > > > \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> > > > \"changes and commit them, and you can discard any commits you make in this\\n\"\n> > > > - \"state without impacting any branches by switching back to a branch.\\n\"\n> > > > + \"state without affecting any branches by switching back to a branch.\\n\"\n> > > > \"\\n\"\n> > > > \"If you want to create a new branch to retain commits you create, you may\\n\"\n> > > > \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> > > > diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> > > > index 3afa81cf9a..24f362d2f4 100644\n> > > > --- a/builtin/fast-import.c\n> > > > +++ b/builtin/fast-import.c\n> > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> > > > const char *prefix)\n> > > > * We don't parse most options until after we've seen the set of\n> > > > * \"feature\" lines at the start of the stream (which allows the command\n> > > > * line to override stream data). But we must do an early parse of any\n> > > > - * command-line options that impact how we interpret the feature lines.\n> > > > + * command-line options that affect how we interpret the feature lines.\n> > > > */\n> > > > for (i = 1; i < argc; i++) {\n> > > > const char *arg = argv[i];\n> > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> > > > index 525c2d8552..749bbca241 100644\n> > > > --- a/builtin/pack-objects.c\n> > > > +++ b/builtin/pack-objects.c\n> > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> > > > /*\n> > > > * Mark ourselves as active and see if the next step causes\n> > > > * us to cycle to another active object. It's important to do\n> > > > - * this _before_ we loop, because it impacts where we make the\n> > > > + * this _before_ we loop, because it affects where we make the\n> > > > * cut, and thus how our total_depth counter works.\n> > > > * E.g., We may see a partial loop like:\n> > > > *\n> > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> > > > index f0e80bd7f0..92979ec770 100644\n> > > > --- a/contrib/coccinelle/README\n> > > > +++ b/contrib/coccinelle/README\n> > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> > > >\n> > > > This allows to expose plans of pending large scale refactorings without\n> > > > - impacting the bad pattern checks.\n> > > > + affecting the bad pattern checks.\n> > > > diff --git a/dir.c b/dir.c\n> > > > index 3474e67e8f..235e26a90e 100644\n> > > > --- a/dir.c\n> > > > +++ b/dir.c\n> > > > @@ -2144,7 +2144,7 @@ static enum path_treatment\n> > > > treat_path_fast(struct dir_struct *dir,\n> > > > /*\n> > > > * We get path_recurse in the first run when\n> > > > * directory_exists_in_index() returns index_nonexistent. We\n> > > > - * are sure that new changes in the index does not impact the\n> > > > + * are sure that new changes in the index does not affect the\n> > > > * outcome. Return now.\n> > > > */\n> > > > return path_recurse;\n> > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> > > > index d0e0e019ea..1fcb98443c 100755\n> > > > --- a/t/perf/p5550-fetch-tags.sh\n> > > > +++ b/t/perf/p5550-fetch-tags.sh\n> > > > @@ -8,7 +8,7 @@ follows.\n> > > >\n> > > > The parent repository has a large number of tags which are disconnected from\n> > > > the rest of history. That makes them candidates for tag-following, but we never\n> > > > -actually grab them (and thus they will impact each subsequent fetch).\n> > > > +actually grab them (and thus they will affect each subsequent fetch).\n> > > >\n> > > > The child repository is a clone of parent, without the tags, and is at least\n> > > > one commit behind the parent (meaning that we will fetch one object and then\n> > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> > > > index a594b4aa7d..95daba4000 100755\n> > > > --- a/t/t0008-ignores.sh\n> > > > +++ b/t/t0008-ignores.sh\n> > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> > > > # test standard ignores\n> > > >\n> > > > # First make sure that the presence of a file in the working tree\n> > > > -# does not impact results, but that the presence of a file in the\n> > > > +# does not affect results, but that the presence of a file in the\n> > > > # index does unless the --no-index option is used.\n> > > >\n> > > > for subdir in '' 'a/'\n> > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> > > > index f028fd1418..a9348f655a 100755\n> > > > --- a/t/t0303-credential-external.sh\n> > > > +++ b/t/t0303-credential-external.sh\n> > > > @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> > > > eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> > > >\n> > > > # clean before the test in case there is cruft left\n> > > > -# over from a previous run that would impact results\n> > > > +# over from a previous run that would affect results\n> > > > helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > >\n> > > > helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> > > > index bc46713a43..568c258c5a 100755\n> > > > --- a/t/t2020-checkout-detach.sh\n> > > > +++ b/t/t2020-checkout-detach.sh\n> > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> > > > no SHA-1 ellipsis when not as\n> > > >\n> > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > changes and commit them, and you can discard any commits you make in this\n> > > > - state without impacting any branches by switching back to a branch.\n> > > > + state without affecting any branches by switching back to a branch.\n> > > >\n> > > > If you want to create a new branch to retain commits you create, you may\n> > > > do so (now or later) by using -c with the switch command. Example:\n> > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> > > > print SHA-1 ellipsis when asked\n> > > >\n> > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > changes and commit them, and you can discard any commits you make in this\n> > > > - state without impacting any branches by switching back to a branch.\n> > > > + state without affecting any branches by switching back to a branch.\n> > > >\n> > > > If you want to create a new branch to retain commits you create, you may\n> > > > do so (now or later) by using -c with the switch command. Example:\n> > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> > > > index 6cca8b84a6..97365a7786 100755\n> > > > --- a/t/t4013-diff-various.sh\n> > > > +++ b/t/t4013-diff-various.sh\n> > > > @@ -109,7 +109,7 @@ test_expect_success setup '\n> > > > git checkout -f master &&\n> > > >\n> > > > # Same merge as master, but with parents reversed. Hide it in a\n> > > > - # pseudo-ref to avoid impacting tests with --all.\n> > > > + # pseudo-ref to avoid affecting tests with --all.\n> > > > commit=$(echo reverse |\n> > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> > > > git update-ref REVERSE $commit &&\n> > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> > > > index 7204799a0b..33a6efce2f 100755\n> > > > --- a/t/t5000-tar-tree.sh\n> > > > +++ b/t/t5000-tar-tree.sh\n> > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> > > > # Pull the size and date of each entry in a tarfile using the system tar.\n> > > > #\n> > > > # We'll pull out only the year from the date; that avoids any question of\n> > > > -# timezones impacting the result (as long as we keep our test times away from a\n> > > > +# timezones affecting the result (as long as we keep our test times away from a\n> > > > # year boundary; our reference times are all in August).\n> > > > #\n> > > > # The output of tar_info is expected to be \" \", both in decimal. It\n> > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> > > > index 6348e8d733..ff65f86f50 100644\n> > > > --- a/t/test-lib-functions.sh\n> > > > +++ b/t/test-lib-functions.sh\n> > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> > > > }\n> > > >\n> > > > # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> > > > -# it also works for shell functions (though those functions cannot impact\n> > > > +# it also works for shell functions (though those functions cannot affect\n> > > > # the environment outside of the test_env invocation).\n> > > > test_env () {\n> > > > (\n> > > > --\n> > > > 2.17.1\n> > > >\n> > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada wrote:\n> > > > >\n> > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King wrote:\n> > > > > >\n> > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n> > > > > >\n> > > > > > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > > > > > problem the word \"impact\" in itself is not \"jargon\".\n> > > > > > >\n> > > > > > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > > > > > strong or market influence\" (n.) when used figuratively; it is not\n> > > > > > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > > > > > all of the entries you've cited. Using it as such is the incorrect\n> > > > > > > part, so those are the instances I've changed in the diff.\n> > > > > >\n> > > > > > Er, is that true? From Michal's definitions:\n> > > > > >\n> > > > > > > > From The Collaborative International Dictionary of English v.0.48 :\n> > > > > > > [...]\n> > > > > > > > 2. To affect or influence, especially in a significant or\n> > > > > >\n> > > > > > It literally uses \"affect\" to define it. The \"especially significant\"\n> > > > > > does not apply to many, but I don't think that makes it necessarily\n> > > > > > wrong to use impact to mean \"affect\".\n> > > > >\n> > > > > I was drawing attention to the \"especially significant\" bit and the\n> > > > > like being there in all the entries. I'm not sure about these\n> > > > > dictionaries, but the definition is hyperbolic / violent / shocking in\n> > > > > every reputable dictionary out there: the Oxford English Dictionary,\n> > > > > Merriam-Webster, and Collins.\n> > > > >\n> > > > > >\n> > > > > > Likewise:\n> > > > > >\n> > > > > > > > From WordNet (r) 3.0 (2006) :\n> > > > > > > [...]\n> > > > > > > > v 1: press or wedge together; pack together\n> > > > > > > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > > > > > > affect, impact, bear upon, bear on, touch on,\n> > > > > > > > touch]\n> > > > > >\n> > > > > > That is likewise listing \"impact\" and \"affect\" as synonyms.\n> > > > > >\n> > > > > > I do agree the word is over-used in some forms of writing, but I don't\n> > > > > > find anything at all confusing or wrong about the uses that you changed\n> > > > > > in your patch. I am a native speaker of English. I'm open to the\n> > > > > > argument that non-native speakers may be more confused by the word. But\n> > > > > > this seems like mostly a style preference thing, and I'd generally\n> > > > > > prefer to leave the contributions and style of the original writers\n> > > > > > intact unless there is a good reason not to.\n> > > > >\n> > > > > I am a native English speaker as well, and there were multiple places\n> > > > > where I had to think twice about what the sentences mean. I agree with\n> > > > > your sentiment about leaving stylistic preferences intact, but this is\n> > > > > actually a semantic one. And given that there is a perfectly good\n> > > > > alternative that doesn't have this confusion / jargon status, I wanted\n> > > > > to make the change to improve it, especially where it says that in the\n> > > > > output of the git command (`git checkout` when in detached HEAD mode).\n> > > > >\n> > > > > >\n> > > > > > Such changes are doubly unwanted in cases like this:\n> > > > > >\n> > > > > > > --- a/compat/nedmalloc/malloc.c.h\n> > > > > > > +++ b/compat/nedmalloc/malloc.c.h\n> > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > > > > > > #endif /* (FOOTERS && !INSECURE) */\n> > > > > > >\n> > > > > > >\n> > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > > > > > > #if !INSECURE\n> > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3\n> > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)\n> > > > > >\n> > > > > > where the text is imported from another project, and we'd prefer to stay\n> > > > > > as close to their version as possible (e.g., to avoid unnecessary\n> > > > > > conflicts when pulling in new versions).\n> > > > >\n> > > > > That's fair; I wasn't aware that this was being pulled directly from\n> > > > > another project. I can change this back.\n> > > > >\n> > > > > >\n> > > > > > Also, this one should be \"effect\" anyway, as it is a noun.\n> > > > >\n> > > > > This seems to have slipped through, as I used a text search tool.\n> > > > >\n> > > > > >\n> > > > > > -Peff\n"},{"id":"423323","messageId":"20210430075924.GB6564@kitsune.suse.cz","threadId":"55436","inReplyTo":"CAD2i4DCLpvAuwp5UEDcPA0wzr4Eg_qhs_xXDW1eLiOwYkUvL1g@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-04-30T07:59:24Z","receivedAt":"2021-04-30T07:59:28Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Thu, Apr 29, 2021 at 08:51:07PM -0500, Varun Varada wrote:\n> On Wed, 28 Apr 2021 at 13:49, Michal Suchánek wrote:\n> >\n> > On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:\n> > > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek wrote:\n> > > >\n> > > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:\n> > > > > Here's the updated diff:\n> > > >\n> > > > As already said multiple general purpose dictionaries recognize '(have)\n> > > > strong effect' as the meaning of 'impact', in some cases even the most\n> > > > common meaning.\n> > >\n> > > There's no contention here. That's the meaning I've been referring to as well.\n> > >\n> > > >\n> > > > In case you have some issue with the word 'jargon' Merriam-Webster gives\n> > > > this definition:\n> > > >\n> > > > 1: the technical terminology or characteristic idiom of a special activity or group\n> > > > 2: obscure and often pretentious language marked by circumlocutions and long words\n> > > > 3a: confused unintelligible language\n> > > > b: a strange, outlandish, or barbarous language or dialect\n> > > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech\n> > > >\n> > > > which the word 'impact' does not fulfill.\n> > > >\n> > > > Further, you would rarely discuss and document an effect that is\n> > > > negligible so in vast majority of cases '(have) strong effect' (ie\n> > > > 'impact') is synonymous to 'affect' and 'affect', respectively.\n> > >\n> > > This is not true, especially in technical contexts. \"Affect\" doesn't\n> > > mean \"has a slight effect on\", but simply \"has an effect on\". This\n> > > suffices in most cases. In cases where one would like to highlight the\n> > > overwhelming/awesome/debilitating/marked/strong effect that something\n> > > has, \"impact\" can be used. To say that every effect is overwhelming or\n> > > strong is jargon.\n> > >\n> > > >\n> > > > If you can pick out a few places where the use is specifically confusing\n> > > > then please pick out those. Wholesale replacement of one word with\n> > > > another synonym is not desired. It creates useless churn.\n> > >\n> > > I've actually not done a wholesale replacement blindly; the ones I\n> > > replaced are the places where I couldn't find any case where it is\n> > > referring to a \"strong/marked effect\". This is especially true in the\n> > > negative constructions. If you could help me find places where you\n> > > think the intended meaning is indeed \"a strong/marked effect\", I can\n> > > remove those from the changes.\n> >\n> > As already pointed out before the mere fact that the author of the text\n> > bothered to document the effect ipmlies that the effect is strong/marked\n> > unless stated otherwise. At any rate 'strong' is always relative. Unless\n> > you have a specific reference of average strenth anything can be\n> > considered strong or weak depending on point of view.\n> \n> This doesn't seem like a plausible or strong argument given the\n> context of the places where I'm editing the text. Most of them are\n> negative constructions, where if one were to assume \"strongly affect\"\n\nThat's not the case. There are some which include negation, and many\nthat don't. I did not review all of the patch so can't really tell but\nit looks like the onse that include negation are a minority or about\nhalf of what you replace at best.\n\n> was intended, then that raises the question of what actual effect it\n> will have. The only convincing example of this I can see is the one\n> where it reads \"which are tight with memory might be badly impacted by\n> this though\". All of the other ones seem like they're binary in\n> whether they will have an effect at all or no, not graduated in terms\n> of the degree of the effect it will have.\n\nWhich also means that the distinction between 'strong effect' and\n'effect' is meaningless, and 'affect' vs 'impact' is synonymous.\nReplacing one with the other is useless churn then.\n\nAlso the cases I saw do not really look confusing in any way so the\nchange does not improve the documentation in any way.\n\n> \n> >\n> > >\n> > > >\n> > > > You could make a case that 'impact' is significantly less frequent word\n> > > > compared to effect/affect and thus makes the text harder to understand\n> > > > for non-native speakers. However, that's not the point you brought up,\n> > > > and even then it is very weak point to make, especially without any\n> > > > actual source for the frequency data. You could also counter that all of\n> > > > these are common loanwords in many languages and are thus easy to\n> > > > understand to non-native speakers anyway.\n> > > >\n> > > > Thanks\n> > > >\n> > > > Michal\n> > > > >\n> > > > > Documentation/MyFirstContribution.txt | 2 +-\n> > > > > Documentation/MyFirstObjectWalk.txt | 2 +-\n> > > > > Documentation/config/pack.txt | 2 +-\n> > > > > Documentation/git-fast-import.txt | 14 +++++++-------\n> > > > > Documentation/git-fetch.txt | 2 +-\n> > > > > .../technical/hash-function-transition.txt | 2 +-\n> > > > > Documentation/user-manual.txt | 4 ++--\n> > > > > advice.c | 2 +-\n> > > > > builtin/fast-import.c | 2 +-\n> > > > > builtin/pack-objects.c | 2 +-\n> > > > > contrib/coccinelle/README | 2 +-\n> > > > > dir.c | 2 +-\n> > > > > t/perf/p5550-fetch-tags.sh | 2 +-\n> > > > > t/t0008-ignores.sh | 2 +-\n> > > > > t/t0303-credential-external.sh | 2 +-\n> > > > > t/t2020-checkout-detach.sh | 4 ++--\n> > > > > t/t4013-diff-various.sh | 2 +-\n> > > > > t/t5000-tar-tree.sh | 2 +-\n> > > > > t/test-lib-functions.sh | 2 +-\n> > > > > 19 files changed, 27 insertions(+), 27 deletions(-)\n> > > > >\n> > > > > diff --git a/Documentation/MyFirstContribution.txt\n> > > > > b/Documentation/MyFirstContribution.txt\n> > > > > index af0a9da62e..8372a7e59e 100644\n> > > > > --- a/Documentation/MyFirstContribution.txt\n> > > > > +++ b/Documentation/MyFirstContribution.txt\n> > > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> > > > > how to show it in the general\n> > > > > command list shown by `git help git` or `git help -a`, which is generated from\n> > > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> > > > > line above it in alphabetical order. Now, we can add some attributes about the\n> > > > > -command which impacts where it shows up in the aforementioned help\n> > > > > commands. The\n> > > > > +command which affects where it shows up in the aforementioned help\n> > > > > commands. The\n> > > > > top of `command-list.txt` shares some information about what each attribute\n> > > > > means; in those help pages, the commands are sorted according to these\n> > > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> > > > > diff --git a/Documentation/MyFirstObjectWalk.txt\n> > > > > b/Documentation/MyFirstObjectWalk.txt\n> > > > > index 2d10eea7a9..fd5bb8fb7d 100644\n> > > > > --- a/Documentation/MyFirstObjectWalk.txt\n> > > > > +++ b/Documentation/MyFirstObjectWalk.txt\n> > > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> > > > > By running your walk with and without the filter, you should find\n> > > > > that the total\n> > > > > object count in each case is identical. You can also time each invocation of\n> > > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> > > > > -to yourself the runtime impact of tracking all omitted objects.\n> > > > > +to yourself the runtime effect of tracking all omitted objects.\n> > > > >\n> > > > > === Changing the Order\n> > > > >\n> > > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> > > > > index 3da4ea98e2..00fcc9d7c7 100644\n> > > > > --- a/Documentation/config/pack.txt\n> > > > > +++ b/Documentation/config/pack.txt\n> > > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> > > > > This cache is used to speed up the writing object phase by not\n> > > > > having to recompute the final delta result once the best match\n> > > > > for all objects is found. Repacking large repositories on machines\n> > > > > - which are tight with memory might be badly impacted by this though,\n> > > > > + which are tight with memory might be badly affected by this though,\n> > > > > especially if this cache pushes the system into swapping.\n> > > > > A value of 0 means no limit. The smallest size of 1 byte may be\n> > > > > used to virtually disable this cache. Defaults to 256 MiB.\n> > > > > diff --git a/Documentation/git-fast-import.txt\n> > > > > b/Documentation/git-fast-import.txt\n> > > > > index 39cfa05b28..c6d8e4e1d7 100644\n> > > > > --- a/Documentation/git-fast-import.txt\n> > > > > +++ b/Documentation/git-fast-import.txt\n> > > > > @@ -58,7 +58,7 @@ OPTIONS\n> > > > > allowing fast-import to access the filesystem outside of the\n> > > > > repository). These options are disabled by default, but can be\n> > > > > allowed by providing this option on the command line. This\n> > > > > - currently impacts only the `export-marks`, `import-marks`, and\n> > > > > + currently affects only the `export-marks`, `import-marks`, and\n> > > > > `import-marks-if-exists` feature commands.\n> > > > > +\n> > > > > Only enable this option if you trust the program generating the\n> > > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> > > > >\n> > > > > A `filecopy` command takes effect immediately. Once the source\n> > > > > location has been copied to the destination any future commands\n> > > > > -applied to the source location will not impact the destination of\n> > > > > +applied to the source location will not affect the destination of\n> > > > > the copy.\n> > > > >\n> > > > > `filerename`\n> > > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> > > > > A `filerename` command takes effect immediately. Once the source\n> > > > > location has been renamed to the destination any future commands\n> > > > > applied to the source location will create new files there and not\n> > > > > -impact the destination of the rename.\n> > > > > +affect the destination of the rename.\n> > > > >\n> > > > > Note that a `filerename` is the same as a `filecopy` followed by a\n> > > > > `filedelete` of the source location. There is a slight performance\n> > > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> > > > > to be required).\n> > > > > ~~~~~~~~~~\n> > > > > Causes fast-import to print the entire `progress` line unmodified to\n> > > > > its standard output channel (file descriptor 1) when the command is\n> > > > > -processed from the input stream. The command otherwise has no impact\n> > > > > +processed from the input stream. The command otherwise has no effect\n> > > > > on the current import, or on any of fast-import's internal state.\n> > > > >\n> > > > > ....\n> > > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> > > > > ~~~~~~~~~~\n> > > > > Causes fast-import to print the SHA-1 corresponding to a mark to\n> > > > > stdout or to the file descriptor previously arranged with the\n> > > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> > > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> > > > > current import; its purpose is to retrieve SHA-1s that later commits\n> > > > > might want to refer to in their commit messages.\n> > > > >\n> > > > > @@ -1050,7 +1050,7 @@ this output safely.\n> > > > > ~~~~~~~~~~\n> > > > > Causes fast-import to print a blob to a file descriptor previously\n> > > > > arranged with the `--cat-blob-fd` argument. The command otherwise\n> > > > > -has no impact on the current import; its main purpose is to\n> > > > > +has no effect on the current import; its main purpose is to\n> > > > > retrieve blobs that may be in fast-import's memory but not\n> > > > > accessible from the target repository.\n> > > > >\n> > > > > @@ -1366,7 +1366,7 @@ code considerably.\n> > > > >\n> > > > > The branch LRU builtin to fast-import tends to behave very well, and the\n> > > > > cost of activating an inactive branch is so low that bouncing around\n> > > > > -between branches has virtually no impact on import performance.\n> > > > > +between branches has virtually no effect on import performance.\n> > > > >\n> > > > > Handling Renames\n> > > > > ~~~~~~~~~~~~~~~~\n> > > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> > > > > index 9067c2079e..01cf3b3d16 100644\n> > > > > --- a/Documentation/git-fetch.txt\n> > > > > +++ b/Documentation/git-fetch.txt\n> > > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> > > > > If left to accumulate, these stale references might make performance\n> > > > > worse on big and busy repos that have a lot of branch churn, and\n> > > > > e.g. make the output of commands like `git branch -a --contains\n> > > > > -` needlessly verbose, as well as impacting anything else\n> > > > > +` needlessly verbose, as well as affecting anything else\n> > > > > that'll work with the complete set of known references.\n> > > > >\n> > > > > These remote-tracking references can be deleted as a one-off with\n> > > > > diff --git a/Documentation/technical/hash-function-transition.txt\n> > > > > b/Documentation/technical/hash-function-transition.txt\n> > > > > index 7c1630bf83..f4296faffc 100644\n> > > > > --- a/Documentation/technical/hash-function-transition.txt\n> > > > > +++ b/Documentation/technical/hash-function-transition.txt\n> > > > > @@ -42,7 +42,7 @@ mitigations.\n> > > > >\n> > > > > If SHA-1 and its variants were to be truly broken, Git's hash function\n> > > > > could not be considered cryptographically secure any more. This would\n> > > > > -impact the communication of hash values because we could not trust\n> > > > > +affect the communication of hash values because we could not trust\n> > > > > that a given hash value represented the known good version of content\n> > > > > that the speaker intended.\n> > > > >\n> > > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > > > > index fd480b8645..33c60c49d7 100644\n> > > > > --- a/Documentation/user-manual.txt\n> > > > > +++ b/Documentation/user-manual.txt\n> > > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> > > > >\n> > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > -state without impacting any branches by performing another switch.\n> > > > > +state without affecting any branches by performing another switch.\n> > > > >\n> > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > do so (now or later) by using -c with the switch command again. Example:\n> > > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> > > > > overwritten by the result of\n> > > > > the merge when this combining is done cleanly, or overwritten by a\n> > > > > half-merged results when this combining results in conflicts.\n> > > > > Therefore, if you have uncommitted changes touching the same files as\n> > > > > -the ones impacted by the merge, Git will refuse to proceed. Most of\n> > > > > +the ones affected by the merge, Git will refuse to proceed. Most of\n> > > > > the time, you will want to commit your changes before you can merge,\n> > > > > and if you don't, then linkgit:git-stash[1] can take these changes\n> > > > > away while you're doing the merge, and reapply them afterwards.\n> > > > > diff --git a/advice.c b/advice.c\n> > > > > index 164742305f..9cbbb824a9 100644\n> > > > > --- a/advice.c\n> > > > > +++ b/advice.c\n> > > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> > > > > \"\\n\"\n> > > > > \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> > > > > \"changes and commit them, and you can discard any commits you make in this\\n\"\n> > > > > - \"state without impacting any branches by switching back to a branch.\\n\"\n> > > > > + \"state without affecting any branches by switching back to a branch.\\n\"\n> > > > > \"\\n\"\n> > > > > \"If you want to create a new branch to retain commits you create, you may\\n\"\n> > > > > \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> > > > > diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> > > > > index 3afa81cf9a..24f362d2f4 100644\n> > > > > --- a/builtin/fast-import.c\n> > > > > +++ b/builtin/fast-import.c\n> > > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> > > > > const char *prefix)\n> > > > > * We don't parse most options until after we've seen the set of\n> > > > > * \"feature\" lines at the start of the stream (which allows the command\n> > > > > * line to override stream data). But we must do an early parse of any\n> > > > > - * command-line options that impact how we interpret the feature lines.\n> > > > > + * command-line options that affect how we interpret the feature lines.\n> > > > > */\n> > > > > for (i = 1; i < argc; i++) {\n> > > > > const char *arg = argv[i];\n> > > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> > > > > index 525c2d8552..749bbca241 100644\n> > > > > --- a/builtin/pack-objects.c\n> > > > > +++ b/builtin/pack-objects.c\n> > > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> > > > > /*\n> > > > > * Mark ourselves as active and see if the next step causes\n> > > > > * us to cycle to another active object. It's important to do\n> > > > > - * this _before_ we loop, because it impacts where we make the\n> > > > > + * this _before_ we loop, because it affects where we make the\n> > > > > * cut, and thus how our total_depth counter works.\n> > > > > * E.g., We may see a partial loop like:\n> > > > > *\n> > > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> > > > > index f0e80bd7f0..92979ec770 100644\n> > > > > --- a/contrib/coccinelle/README\n> > > > > +++ b/contrib/coccinelle/README\n> > > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> > > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> > > > >\n> > > > > This allows to expose plans of pending large scale refactorings without\n> > > > > - impacting the bad pattern checks.\n> > > > > + affecting the bad pattern checks.\n> > > > > diff --git a/dir.c b/dir.c\n> > > > > index 3474e67e8f..235e26a90e 100644\n> > > > > --- a/dir.c\n> > > > > +++ b/dir.c\n> > > > > @@ -2144,7 +2144,7 @@ static enum path_treatment\n> > > > > treat_path_fast(struct dir_struct *dir,\n> > > > > /*\n> > > > > * We get path_recurse in the first run when\n> > > > > * directory_exists_in_index() returns index_nonexistent. We\n> > > > > - * are sure that new changes in the index does not impact the\n> > > > > + * are sure that new changes in the index does not affect the\n> > > > > * outcome. Return now.\n> > > > > */\n> > > > > return path_recurse;\n> > > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> > > > > index d0e0e019ea..1fcb98443c 100755\n> > > > > --- a/t/perf/p5550-fetch-tags.sh\n> > > > > +++ b/t/perf/p5550-fetch-tags.sh\n> > > > > @@ -8,7 +8,7 @@ follows.\n> > > > >\n> > > > > The parent repository has a large number of tags which are disconnected from\n> > > > > the rest of history. That makes them candidates for tag-following, but we never\n> > > > > -actually grab them (and thus they will impact each subsequent fetch).\n> > > > > +actually grab them (and thus they will affect each subsequent fetch).\n> > > > >\n> > > > > The child repository is a clone of parent, without the tags, and is at least\n> > > > > one commit behind the parent (meaning that we will fetch one object and then\n> > > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> > > > > index a594b4aa7d..95daba4000 100755\n> > > > > --- a/t/t0008-ignores.sh\n> > > > > +++ b/t/t0008-ignores.sh\n> > > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> > > > > # test standard ignores\n> > > > >\n> > > > > # First make sure that the presence of a file in the working tree\n> > > > > -# does not impact results, but that the presence of a file in the\n> > > > > +# does not affect results, but that the presence of a file in the\n> > > > > # index does unless the --no-index option is used.\n> > > > >\n> > > > > for subdir in '' 'a/'\n> > > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> > > > > index f028fd1418..a9348f655a 100755\n> > > > > --- a/t/t0303-credential-external.sh\n> > > > > +++ b/t/t0303-credential-external.sh\n> > > > > @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> > > > > eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> > > > >\n> > > > > # clean before the test in case there is cruft left\n> > > > > -# over from a previous run that would impact results\n> > > > > +# over from a previous run that would affect results\n> > > > > helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > > >\n> > > > > helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> > > > > index bc46713a43..568c258c5a 100755\n> > > > > --- a/t/t2020-checkout-detach.sh\n> > > > > +++ b/t/t2020-checkout-detach.sh\n> > > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> > > > > no SHA-1 ellipsis when not as\n> > > > >\n> > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > - state without impacting any branches by switching back to a branch.\n> > > > > + state without affecting any branches by switching back to a branch.\n> > > > >\n> > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > do so (now or later) by using -c with the switch command. Example:\n> > > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> > > > > print SHA-1 ellipsis when asked\n> > > > >\n> > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > - state without impacting any branches by switching back to a branch.\n> > > > > + state without affecting any branches by switching back to a branch.\n> > > > >\n> > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > do so (now or later) by using -c with the switch command. Example:\n> > > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> > > > > index 6cca8b84a6..97365a7786 100755\n> > > > > --- a/t/t4013-diff-various.sh\n> > > > > +++ b/t/t4013-diff-various.sh\n> > > > > @@ -109,7 +109,7 @@ test_expect_success setup '\n> > > > > git checkout -f master &&\n> > > > >\n> > > > > # Same merge as master, but with parents reversed. Hide it in a\n> > > > > - # pseudo-ref to avoid impacting tests with --all.\n> > > > > + # pseudo-ref to avoid affecting tests with --all.\n> > > > > commit=$(echo reverse |\n> > > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> > > > > git update-ref REVERSE $commit &&\n> > > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> > > > > index 7204799a0b..33a6efce2f 100755\n> > > > > --- a/t/t5000-tar-tree.sh\n> > > > > +++ b/t/t5000-tar-tree.sh\n> > > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> > > > > # Pull the size and date of each entry in a tarfile using the system tar.\n> > > > > #\n> > > > > # We'll pull out only the year from the date; that avoids any question of\n> > > > > -# timezones impacting the result (as long as we keep our test times away from a\n> > > > > +# timezones affecting the result (as long as we keep our test times away from a\n> > > > > # year boundary; our reference times are all in August).\n> > > > > #\n> > > > > # The output of tar_info is expected to be \" \", both in decimal. It\n> > > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> > > > > index 6348e8d733..ff65f86f50 100644\n> > > > > --- a/t/test-lib-functions.sh\n> > > > > +++ b/t/test-lib-functions.sh\n> > > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> > > > > }\n> > > > >\n> > > > > # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> > > > > -# it also works for shell functions (though those functions cannot impact\n> > > > > +# it also works for shell functions (though those functions cannot affect\n> > > > > # the environment outside of the test_env invocation).\n> > > > > test_env () {\n> > > > > (\n> > > > > --\n> > > > > 2.17.1\n> > > > >\n> > > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada wrote:\n> > > > > >\n> > > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King wrote:\n> > > > > > >\n> > > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n> > > > > > >\n> > > > > > > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > > > > > > problem the word \"impact\" in itself is not \"jargon\".\n> > > > > > > >\n> > > > > > > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > > > > > > strong or market influence\" (n.) when used figuratively; it is not\n> > > > > > > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > > > > > > all of the entries you've cited. Using it as such is the incorrect\n> > > > > > > > part, so those are the instances I've changed in the diff.\n> > > > > > >\n> > > > > > > Er, is that true? From Michal's definitions:\n> > > > > > >\n> > > > > > > > > From The Collaborative International Dictionary of English v.0.48 :\n> > > > > > > > [...]\n> > > > > > > > > 2. To affect or influence, especially in a significant or\n> > > > > > >\n> > > > > > > It literally uses \"affect\" to define it. The \"especially significant\"\n> > > > > > > does not apply to many, but I don't think that makes it necessarily\n> > > > > > > wrong to use impact to mean \"affect\".\n> > > > > >\n> > > > > > I was drawing attention to the \"especially significant\" bit and the\n> > > > > > like being there in all the entries. I'm not sure about these\n> > > > > > dictionaries, but the definition is hyperbolic / violent / shocking in\n> > > > > > every reputable dictionary out there: the Oxford English Dictionary,\n> > > > > > Merriam-Webster, and Collins.\n> > > > > >\n> > > > > > >\n> > > > > > > Likewise:\n> > > > > > >\n> > > > > > > > > From WordNet (r) 3.0 (2006) :\n> > > > > > > > [...]\n> > > > > > > > > v 1: press or wedge together; pack together\n> > > > > > > > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > > > > > > > affect, impact, bear upon, bear on, touch on,\n> > > > > > > > > touch]\n> > > > > > >\n> > > > > > > That is likewise listing \"impact\" and \"affect\" as synonyms.\n> > > > > > >\n> > > > > > > I do agree the word is over-used in some forms of writing, but I don't\n> > > > > > > find anything at all confusing or wrong about the uses that you changed\n> > > > > > > in your patch. I am a native speaker of English. I'm open to the\n> > > > > > > argument that non-native speakers may be more confused by the word. But\n> > > > > > > this seems like mostly a style preference thing, and I'd generally\n> > > > > > > prefer to leave the contributions and style of the original writers\n> > > > > > > intact unless there is a good reason not to.\n> > > > > >\n> > > > > > I am a native English speaker as well, and there were multiple places\n> > > > > > where I had to think twice about what the sentences mean. I agree with\n> > > > > > your sentiment about leaving stylistic preferences intact, but this is\n> > > > > > actually a semantic one. And given that there is a perfectly good\n> > > > > > alternative that doesn't have this confusion / jargon status, I wanted\n> > > > > > to make the change to improve it, especially where it says that in the\n> > > > > > output of the git command (`git checkout` when in detached HEAD mode).\n> > > > > >\n> > > > > > >\n> > > > > > > Such changes are doubly unwanted in cases like this:\n> > > > > > >\n> > > > > > > > --- a/compat/nedmalloc/malloc.c.h\n> > > > > > > > +++ b/compat/nedmalloc/malloc.c.h\n> > > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > > > > > > > #endif /* (FOOTERS && !INSECURE) */\n> > > > > > > >\n> > > > > > > >\n> > > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > > > > > > > #if !INSECURE\n> > > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3\n> > > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)\n> > > > > > >\n> > > > > > > where the text is imported from another project, and we'd prefer to stay\n> > > > > > > as close to their version as possible (e.g., to avoid unnecessary\n> > > > > > > conflicts when pulling in new versions).\n> > > > > >\n> > > > > > That's fair; I wasn't aware that this was being pulled directly from\n> > > > > > another project. I can change this back.\n> > > > > >\n> > > > > > >\n> > > > > > > Also, this one should be \"effect\" anyway, as it is a noun.\n> > > > > >\n> > > > > > This seems to have slipped through, as I used a text search tool.\n> > > > > >\n> > > > > > >\n> > > > > > > -Peff\n"},{"id":"424059","messageId":"CAD2i4DBSajgNFCwMMDv_tyQwuKDU095avmHs=BHcrAY1GbCqwA@mail.gmail.com","threadId":"55436","inReplyTo":"20210430075924.GB6564@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-05-10T17:19:05Z","receivedAt":"2021-05-10T17:19:22Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Fri, 30 Apr 2021 at 02:59, Michal Suchánek wrote:\n>\n> On Thu, Apr 29, 2021 at 08:51:07PM -0500, Varun Varada wrote:\n> > On Wed, 28 Apr 2021 at 13:49, Michal Suchánek wrote:\n> > >\n> > > On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:\n> > > > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek wrote:\n> > > > >\n> > > > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:\n> > > > > > Here's the updated diff:\n> > > > >\n> > > > > As already said multiple general purpose dictionaries recognize '(have)\n> > > > > strong effect' as the meaning of 'impact', in some cases even the most\n> > > > > common meaning.\n> > > >\n> > > > There's no contention here. That's the meaning I've been referring to as well.\n> > > >\n> > > > >\n> > > > > In case you have some issue with the word 'jargon' Merriam-Webster gives\n> > > > > this definition:\n> > > > >\n> > > > > 1: the technical terminology or characteristic idiom of a special activity or group\n> > > > > 2: obscure and often pretentious language marked by circumlocutions and long words\n> > > > > 3a: confused unintelligible language\n> > > > > b: a strange, outlandish, or barbarous language or dialect\n> > > > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech\n> > > > >\n> > > > > which the word 'impact' does not fulfill.\n> > > > >\n> > > > > Further, you would rarely discuss and document an effect that is\n> > > > > negligible so in vast majority of cases '(have) strong effect' (ie\n> > > > > 'impact') is synonymous to 'affect' and 'affect', respectively.\n> > > >\n> > > > This is not true, especially in technical contexts. \"Affect\" doesn't\n> > > > mean \"has a slight effect on\", but simply \"has an effect on\". This\n> > > > suffices in most cases. In cases where one would like to highlight the\n> > > > overwhelming/awesome/debilitating/marked/strong effect that something\n> > > > has, \"impact\" can be used. To say that every effect is overwhelming or\n> > > > strong is jargon.\n> > > >\n> > > > >\n> > > > > If you can pick out a few places where the use is specifically confusing\n> > > > > then please pick out those. Wholesale replacement of one word with\n> > > > > another synonym is not desired. It creates useless churn.\n> > > >\n> > > > I've actually not done a wholesale replacement blindly; the ones I\n> > > > replaced are the places where I couldn't find any case where it is\n> > > > referring to a \"strong/marked effect\". This is especially true in the\n> > > > negative constructions. If you could help me find places where you\n> > > > think the intended meaning is indeed \"a strong/marked effect\", I can\n> > > > remove those from the changes.\n> > >\n> > > As already pointed out before the mere fact that the author of the text\n> > > bothered to document the effect ipmlies that the effect is strong/marked\n> > > unless stated otherwise. At any rate 'strong' is always relative. Unless\n> > > you have a specific reference of average strenth anything can be\n> > > considered strong or weak depending on point of view.\n> >\n> > This doesn't seem like a plausible or strong argument given the\n> > context of the places where I'm editing the text. Most of them are\n> > negative constructions, where if one were to assume \"strongly affect\"\n>\n> That's not the case. There are some which include negation, and many\n> that don't. I did not review all of the patch so can't really tell but\n> it looks like the onse that include negation are a minority or about\n> half of what you replace at best.\n\nThere are 27 changes, 16 of which are negation. That's more than half,\nand at least all of these need to be replaced.\n\n>\n> > was intended, then that raises the question of what actual effect it\n> > will have. The only convincing example of this I can see is the one\n> > where it reads \"which are tight with memory might be badly impacted by\n> > this though\". All of the other ones seem like they're binary in\n> > whether they will have an effect at all or no, not graduated in terms\n> > of the degree of the effect it will have.\n>\n> Which also means that the distinction between 'strong effect' and\n> 'effect' is meaningless, and 'affect' vs 'impact' is synonymous.\n> Replacing one with the other is useless churn then.\n\nI'm not sure I understand what you mean by \"churn\". No one would stop\nusing Git because of these single-word changes.\n\nAs for there being no distinction, there's no gradation within the\nsemantics of this context; this doesn't change the semantics of the\nwords themselves. Using \"impact\" when what is meant is just \"effect\"\nor \"affect\" is incorrect in all such instances.\n\n>\n> Also the cases I saw do not really look confusing in any way so the\n> change does not improve the documentation in any way.\n\nSaying \"will not impact\" means \"will not strongly affect\", as you've\nalready agreed. This necessarily means it might affect it, albeit not\nstrongly. This is confusing to anyone reading the documentation, and\nis entirely unnecessary. I don't understand the resistance here for\nsimple one-word changes that remove this confusion. Am I missing\nsomething?\n\n>\n> >\n> > >\n> > > >\n> > > > >\n> > > > > You could make a case that 'impact' is significantly less frequent word\n> > > > > compared to effect/affect and thus makes the text harder to understand\n> > > > > for non-native speakers. However, that's not the point you brought up,\n> > > > > and even then it is very weak point to make, especially without any\n> > > > > actual source for the frequency data. You could also counter that all of\n> > > > > these are common loanwords in many languages and are thus easy to\n> > > > > understand to non-native speakers anyway.\n> > > > >\n> > > > > Thanks\n> > > > >\n> > > > > Michal\n> > > > > >\n> > > > > > Documentation/MyFirstContribution.txt | 2 +-\n> > > > > > Documentation/MyFirstObjectWalk.txt | 2 +-\n> > > > > > Documentation/config/pack.txt | 2 +-\n> > > > > > Documentation/git-fast-import.txt | 14 +++++++-------\n> > > > > > Documentation/git-fetch.txt | 2 +-\n> > > > > > .../technical/hash-function-transition.txt | 2 +-\n> > > > > > Documentation/user-manual.txt | 4 ++--\n> > > > > > advice.c | 2 +-\n> > > > > > builtin/fast-import.c | 2 +-\n> > > > > > builtin/pack-objects.c | 2 +-\n> > > > > > contrib/coccinelle/README | 2 +-\n> > > > > > dir.c | 2 +-\n> > > > > > t/perf/p5550-fetch-tags.sh | 2 +-\n> > > > > > t/t0008-ignores.sh | 2 +-\n> > > > > > t/t0303-credential-external.sh | 2 +-\n> > > > > > t/t2020-checkout-detach.sh | 4 ++--\n> > > > > > t/t4013-diff-various.sh | 2 +-\n> > > > > > t/t5000-tar-tree.sh | 2 +-\n> > > > > > t/test-lib-functions.sh | 2 +-\n> > > > > > 19 files changed, 27 insertions(+), 27 deletions(-)\n> > > > > >\n> > > > > > diff --git a/Documentation/MyFirstContribution.txt\n> > > > > > b/Documentation/MyFirstContribution.txt\n> > > > > > index af0a9da62e..8372a7e59e 100644\n> > > > > > --- a/Documentation/MyFirstContribution.txt\n> > > > > > +++ b/Documentation/MyFirstContribution.txt\n> > > > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> > > > > > how to show it in the general\n> > > > > > command list shown by `git help git` or `git help -a`, which is generated from\n> > > > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> > > > > > line above it in alphabetical order. Now, we can add some attributes about the\n> > > > > > -command which impacts where it shows up in the aforementioned help\n> > > > > > commands. The\n> > > > > > +command which affects where it shows up in the aforementioned help\n> > > > > > commands. The\n> > > > > > top of `command-list.txt` shares some information about what each attribute\n> > > > > > means; in those help pages, the commands are sorted according to these\n> > > > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> > > > > > diff --git a/Documentation/MyFirstObjectWalk.txt\n> > > > > > b/Documentation/MyFirstObjectWalk.txt\n> > > > > > index 2d10eea7a9..fd5bb8fb7d 100644\n> > > > > > --- a/Documentation/MyFirstObjectWalk.txt\n> > > > > > +++ b/Documentation/MyFirstObjectWalk.txt\n> > > > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> > > > > > By running your walk with and without the filter, you should find\n> > > > > > that the total\n> > > > > > object count in each case is identical. You can also time each invocation of\n> > > > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> > > > > > -to yourself the runtime impact of tracking all omitted objects.\n> > > > > > +to yourself the runtime effect of tracking all omitted objects.\n> > > > > >\n> > > > > > === Changing the Order\n> > > > > >\n> > > > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> > > > > > index 3da4ea98e2..00fcc9d7c7 100644\n> > > > > > --- a/Documentation/config/pack.txt\n> > > > > > +++ b/Documentation/config/pack.txt\n> > > > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> > > > > > This cache is used to speed up the writing object phase by not\n> > > > > > having to recompute the final delta result once the best match\n> > > > > > for all objects is found. Repacking large repositories on machines\n> > > > > > - which are tight with memory might be badly impacted by this though,\n> > > > > > + which are tight with memory might be badly affected by this though,\n> > > > > > especially if this cache pushes the system into swapping.\n> > > > > > A value of 0 means no limit. The smallest size of 1 byte may be\n> > > > > > used to virtually disable this cache. Defaults to 256 MiB.\n> > > > > > diff --git a/Documentation/git-fast-import.txt\n> > > > > > b/Documentation/git-fast-import.txt\n> > > > > > index 39cfa05b28..c6d8e4e1d7 100644\n> > > > > > --- a/Documentation/git-fast-import.txt\n> > > > > > +++ b/Documentation/git-fast-import.txt\n> > > > > > @@ -58,7 +58,7 @@ OPTIONS\n> > > > > > allowing fast-import to access the filesystem outside of the\n> > > > > > repository). These options are disabled by default, but can be\n> > > > > > allowed by providing this option on the command line. This\n> > > > > > - currently impacts only the `export-marks`, `import-marks`, and\n> > > > > > + currently affects only the `export-marks`, `import-marks`, and\n> > > > > > `import-marks-if-exists` feature commands.\n> > > > > > +\n> > > > > > Only enable this option if you trust the program generating the\n> > > > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> > > > > >\n> > > > > > A `filecopy` command takes effect immediately. Once the source\n> > > > > > location has been copied to the destination any future commands\n> > > > > > -applied to the source location will not impact the destination of\n> > > > > > +applied to the source location will not affect the destination of\n> > > > > > the copy.\n> > > > > >\n> > > > > > `filerename`\n> > > > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> > > > > > A `filerename` command takes effect immediately. Once the source\n> > > > > > location has been renamed to the destination any future commands\n> > > > > > applied to the source location will create new files there and not\n> > > > > > -impact the destination of the rename.\n> > > > > > +affect the destination of the rename.\n> > > > > >\n> > > > > > Note that a `filerename` is the same as a `filecopy` followed by a\n> > > > > > `filedelete` of the source location. There is a slight performance\n> > > > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> > > > > > to be required).\n> > > > > > ~~~~~~~~~~\n> > > > > > Causes fast-import to print the entire `progress` line unmodified to\n> > > > > > its standard output channel (file descriptor 1) when the command is\n> > > > > > -processed from the input stream. The command otherwise has no impact\n> > > > > > +processed from the input stream. The command otherwise has no effect\n> > > > > > on the current import, or on any of fast-import's internal state.\n> > > > > >\n> > > > > > ....\n> > > > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> > > > > > ~~~~~~~~~~\n> > > > > > Causes fast-import to print the SHA-1 corresponding to a mark to\n> > > > > > stdout or to the file descriptor previously arranged with the\n> > > > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> > > > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> > > > > > current import; its purpose is to retrieve SHA-1s that later commits\n> > > > > > might want to refer to in their commit messages.\n> > > > > >\n> > > > > > @@ -1050,7 +1050,7 @@ this output safely.\n> > > > > > ~~~~~~~~~~\n> > > > > > Causes fast-import to print a blob to a file descriptor previously\n> > > > > > arranged with the `--cat-blob-fd` argument. The command otherwise\n> > > > > > -has no impact on the current import; its main purpose is to\n> > > > > > +has no effect on the current import; its main purpose is to\n> > > > > > retrieve blobs that may be in fast-import's memory but not\n> > > > > > accessible from the target repository.\n> > > > > >\n> > > > > > @@ -1366,7 +1366,7 @@ code considerably.\n> > > > > >\n> > > > > > The branch LRU builtin to fast-import tends to behave very well, and the\n> > > > > > cost of activating an inactive branch is so low that bouncing around\n> > > > > > -between branches has virtually no impact on import performance.\n> > > > > > +between branches has virtually no effect on import performance.\n> > > > > >\n> > > > > > Handling Renames\n> > > > > > ~~~~~~~~~~~~~~~~\n> > > > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> > > > > > index 9067c2079e..01cf3b3d16 100644\n> > > > > > --- a/Documentation/git-fetch.txt\n> > > > > > +++ b/Documentation/git-fetch.txt\n> > > > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> > > > > > If left to accumulate, these stale references might make performance\n> > > > > > worse on big and busy repos that have a lot of branch churn, and\n> > > > > > e.g. make the output of commands like `git branch -a --contains\n> > > > > > -` needlessly verbose, as well as impacting anything else\n> > > > > > +` needlessly verbose, as well as affecting anything else\n> > > > > > that'll work with the complete set of known references.\n> > > > > >\n> > > > > > These remote-tracking references can be deleted as a one-off with\n> > > > > > diff --git a/Documentation/technical/hash-function-transition.txt\n> > > > > > b/Documentation/technical/hash-function-transition.txt\n> > > > > > index 7c1630bf83..f4296faffc 100644\n> > > > > > --- a/Documentation/technical/hash-function-transition.txt\n> > > > > > +++ b/Documentation/technical/hash-function-transition.txt\n> > > > > > @@ -42,7 +42,7 @@ mitigations.\n> > > > > >\n> > > > > > If SHA-1 and its variants were to be truly broken, Git's hash function\n> > > > > > could not be considered cryptographically secure any more. This would\n> > > > > > -impact the communication of hash values because we could not trust\n> > > > > > +affect the communication of hash values because we could not trust\n> > > > > > that a given hash value represented the known good version of content\n> > > > > > that the speaker intended.\n> > > > > >\n> > > > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > > > > > index fd480b8645..33c60c49d7 100644\n> > > > > > --- a/Documentation/user-manual.txt\n> > > > > > +++ b/Documentation/user-manual.txt\n> > > > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> > > > > >\n> > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > -state without impacting any branches by performing another switch.\n> > > > > > +state without affecting any branches by performing another switch.\n> > > > > >\n> > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > do so (now or later) by using -c with the switch command again. Example:\n> > > > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> > > > > > overwritten by the result of\n> > > > > > the merge when this combining is done cleanly, or overwritten by a\n> > > > > > half-merged results when this combining results in conflicts.\n> > > > > > Therefore, if you have uncommitted changes touching the same files as\n> > > > > > -the ones impacted by the merge, Git will refuse to proceed. Most of\n> > > > > > +the ones affected by the merge, Git will refuse to proceed. Most of\n> > > > > > the time, you will want to commit your changes before you can merge,\n> > > > > > and if you don't, then linkgit:git-stash[1] can take these changes\n> > > > > > away while you're doing the merge, and reapply them afterwards.\n> > > > > > diff --git a/advice.c b/advice.c\n> > > > > > index 164742305f..9cbbb824a9 100644\n> > > > > > --- a/advice.c\n> > > > > > +++ b/advice.c\n> > > > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> > > > > > \"\\n\"\n> > > > > > \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> > > > > > \"changes and commit them, and you can discard any commits you make in this\\n\"\n> > > > > > - \"state without impacting any branches by switching back to a branch.\\n\"\n> > > > > > + \"state without affecting any branches by switching back to a branch.\\n\"\n> > > > > > \"\\n\"\n> > > > > > \"If you want to create a new branch to retain commits you create, you may\\n\"\n> > > > > > \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> > > > > > diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> > > > > > index 3afa81cf9a..24f362d2f4 100644\n> > > > > > --- a/builtin/fast-import.c\n> > > > > > +++ b/builtin/fast-import.c\n> > > > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> > > > > > const char *prefix)\n> > > > > > * We don't parse most options until after we've seen the set of\n> > > > > > * \"feature\" lines at the start of the stream (which allows the command\n> > > > > > * line to override stream data). But we must do an early parse of any\n> > > > > > - * command-line options that impact how we interpret the feature lines.\n> > > > > > + * command-line options that affect how we interpret the feature lines.\n> > > > > > */\n> > > > > > for (i = 1; i < argc; i++) {\n> > > > > > const char *arg = argv[i];\n> > > > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> > > > > > index 525c2d8552..749bbca241 100644\n> > > > > > --- a/builtin/pack-objects.c\n> > > > > > +++ b/builtin/pack-objects.c\n> > > > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> > > > > > /*\n> > > > > > * Mark ourselves as active and see if the next step causes\n> > > > > > * us to cycle to another active object. It's important to do\n> > > > > > - * this _before_ we loop, because it impacts where we make the\n> > > > > > + * this _before_ we loop, because it affects where we make the\n> > > > > > * cut, and thus how our total_depth counter works.\n> > > > > > * E.g., We may see a partial loop like:\n> > > > > > *\n> > > > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> > > > > > index f0e80bd7f0..92979ec770 100644\n> > > > > > --- a/contrib/coccinelle/README\n> > > > > > +++ b/contrib/coccinelle/README\n> > > > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> > > > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> > > > > >\n> > > > > > This allows to expose plans of pending large scale refactorings without\n> > > > > > - impacting the bad pattern checks.\n> > > > > > + affecting the bad pattern checks.\n> > > > > > diff --git a/dir.c b/dir.c\n> > > > > > index 3474e67e8f..235e26a90e 100644\n> > > > > > --- a/dir.c\n> > > > > > +++ b/dir.c\n> > > > > > @@ -2144,7 +2144,7 @@ static enum path_treatment\n> > > > > > treat_path_fast(struct dir_struct *dir,\n> > > > > > /*\n> > > > > > * We get path_recurse in the first run when\n> > > > > > * directory_exists_in_index() returns index_nonexistent. We\n> > > > > > - * are sure that new changes in the index does not impact the\n> > > > > > + * are sure that new changes in the index does not affect the\n> > > > > > * outcome. Return now.\n> > > > > > */\n> > > > > > return path_recurse;\n> > > > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> > > > > > index d0e0e019ea..1fcb98443c 100755\n> > > > > > --- a/t/perf/p5550-fetch-tags.sh\n> > > > > > +++ b/t/perf/p5550-fetch-tags.sh\n> > > > > > @@ -8,7 +8,7 @@ follows.\n> > > > > >\n> > > > > > The parent repository has a large number of tags which are disconnected from\n> > > > > > the rest of history. That makes them candidates for tag-following, but we never\n> > > > > > -actually grab them (and thus they will impact each subsequent fetch).\n> > > > > > +actually grab them (and thus they will affect each subsequent fetch).\n> > > > > >\n> > > > > > The child repository is a clone of parent, without the tags, and is at least\n> > > > > > one commit behind the parent (meaning that we will fetch one object and then\n> > > > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> > > > > > index a594b4aa7d..95daba4000 100755\n> > > > > > --- a/t/t0008-ignores.sh\n> > > > > > +++ b/t/t0008-ignores.sh\n> > > > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> > > > > > # test standard ignores\n> > > > > >\n> > > > > > # First make sure that the presence of a file in the working tree\n> > > > > > -# does not impact results, but that the presence of a file in the\n> > > > > > +# does not affect results, but that the presence of a file in the\n> > > > > > # index does unless the --no-index option is used.\n> > > > > >\n> > > > > > for subdir in '' 'a/'\n> > > > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> > > > > > index f028fd1418..a9348f655a 100755\n> > > > > > --- a/t/t0303-credential-external.sh\n> > > > > > +++ b/t/t0303-credential-external.sh\n> > > > > > @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> > > > > > eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> > > > > >\n> > > > > > # clean before the test in case there is cruft left\n> > > > > > -# over from a previous run that would impact results\n> > > > > > +# over from a previous run that would affect results\n> > > > > > helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > > > >\n> > > > > > helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> > > > > > index bc46713a43..568c258c5a 100755\n> > > > > > --- a/t/t2020-checkout-detach.sh\n> > > > > > +++ b/t/t2020-checkout-detach.sh\n> > > > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> > > > > > no SHA-1 ellipsis when not as\n> > > > > >\n> > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > - state without impacting any branches by switching back to a branch.\n> > > > > > + state without affecting any branches by switching back to a branch.\n> > > > > >\n> > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > do so (now or later) by using -c with the switch command. Example:\n> > > > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> > > > > > print SHA-1 ellipsis when asked\n> > > > > >\n> > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > - state without impacting any branches by switching back to a branch.\n> > > > > > + state without affecting any branches by switching back to a branch.\n> > > > > >\n> > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > do so (now or later) by using -c with the switch command. Example:\n> > > > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> > > > > > index 6cca8b84a6..97365a7786 100755\n> > > > > > --- a/t/t4013-diff-various.sh\n> > > > > > +++ b/t/t4013-diff-various.sh\n> > > > > > @@ -109,7 +109,7 @@ test_expect_success setup '\n> > > > > > git checkout -f master &&\n> > > > > >\n> > > > > > # Same merge as master, but with parents reversed. Hide it in a\n> > > > > > - # pseudo-ref to avoid impacting tests with --all.\n> > > > > > + # pseudo-ref to avoid affecting tests with --all.\n> > > > > > commit=$(echo reverse |\n> > > > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> > > > > > git update-ref REVERSE $commit &&\n> > > > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> > > > > > index 7204799a0b..33a6efce2f 100755\n> > > > > > --- a/t/t5000-tar-tree.sh\n> > > > > > +++ b/t/t5000-tar-tree.sh\n> > > > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> > > > > > # Pull the size and date of each entry in a tarfile using the system tar.\n> > > > > > #\n> > > > > > # We'll pull out only the year from the date; that avoids any question of\n> > > > > > -# timezones impacting the result (as long as we keep our test times away from a\n> > > > > > +# timezones affecting the result (as long as we keep our test times away from a\n> > > > > > # year boundary; our reference times are all in August).\n> > > > > > #\n> > > > > > # The output of tar_info is expected to be \" \", both in decimal. It\n> > > > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> > > > > > index 6348e8d733..ff65f86f50 100644\n> > > > > > --- a/t/test-lib-functions.sh\n> > > > > > +++ b/t/test-lib-functions.sh\n> > > > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> > > > > > }\n> > > > > >\n> > > > > > # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> > > > > > -# it also works for shell functions (though those functions cannot impact\n> > > > > > +# it also works for shell functions (though those functions cannot affect\n> > > > > > # the environment outside of the test_env invocation).\n> > > > > > test_env () {\n> > > > > > (\n> > > > > > --\n> > > > > > 2.17.1\n> > > > > >\n> > > > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada wrote:\n> > > > > > >\n> > > > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King wrote:\n> > > > > > > >\n> > > > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n> > > > > > > >\n> > > > > > > > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > > > > > > > problem the word \"impact\" in itself is not \"jargon\".\n> > > > > > > > >\n> > > > > > > > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > > > > > > > strong or market influence\" (n.) when used figuratively; it is not\n> > > > > > > > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > > > > > > > all of the entries you've cited. Using it as such is the incorrect\n> > > > > > > > > part, so those are the instances I've changed in the diff.\n> > > > > > > >\n> > > > > > > > Er, is that true? From Michal's definitions:\n> > > > > > > >\n> > > > > > > > > > From The Collaborative International Dictionary of English v.0.48 :\n> > > > > > > > > [...]\n> > > > > > > > > > 2. To affect or influence, especially in a significant or\n> > > > > > > >\n> > > > > > > > It literally uses \"affect\" to define it. The \"especially significant\"\n> > > > > > > > does not apply to many, but I don't think that makes it necessarily\n> > > > > > > > wrong to use impact to mean \"affect\".\n> > > > > > >\n> > > > > > > I was drawing attention to the \"especially significant\" bit and the\n> > > > > > > like being there in all the entries. I'm not sure about these\n> > > > > > > dictionaries, but the definition is hyperbolic / violent / shocking in\n> > > > > > > every reputable dictionary out there: the Oxford English Dictionary,\n> > > > > > > Merriam-Webster, and Collins.\n> > > > > > >\n> > > > > > > >\n> > > > > > > > Likewise:\n> > > > > > > >\n> > > > > > > > > > From WordNet (r) 3.0 (2006) :\n> > > > > > > > > [...]\n> > > > > > > > > > v 1: press or wedge together; pack together\n> > > > > > > > > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > > > > > > > > affect, impact, bear upon, bear on, touch on,\n> > > > > > > > > > touch]\n> > > > > > > >\n> > > > > > > > That is likewise listing \"impact\" and \"affect\" as synonyms.\n> > > > > > > >\n> > > > > > > > I do agree the word is over-used in some forms of writing, but I don't\n> > > > > > > > find anything at all confusing or wrong about the uses that you changed\n> > > > > > > > in your patch. I am a native speaker of English. I'm open to the\n> > > > > > > > argument that non-native speakers may be more confused by the word. But\n> > > > > > > > this seems like mostly a style preference thing, and I'd generally\n> > > > > > > > prefer to leave the contributions and style of the original writers\n> > > > > > > > intact unless there is a good reason not to.\n> > > > > > >\n> > > > > > > I am a native English speaker as well, and there were multiple places\n> > > > > > > where I had to think twice about what the sentences mean. I agree with\n> > > > > > > your sentiment about leaving stylistic preferences intact, but this is\n> > > > > > > actually a semantic one. And given that there is a perfectly good\n> > > > > > > alternative that doesn't have this confusion / jargon status, I wanted\n> > > > > > > to make the change to improve it, especially where it says that in the\n> > > > > > > output of the git command (`git checkout` when in detached HEAD mode).\n> > > > > > >\n> > > > > > > >\n> > > > > > > > Such changes are doubly unwanted in cases like this:\n> > > > > > > >\n> > > > > > > > > --- a/compat/nedmalloc/malloc.c.h\n> > > > > > > > > +++ b/compat/nedmalloc/malloc.c.h\n> > > > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > > > > > > > > #endif /* (FOOTERS && !INSECURE) */\n> > > > > > > > >\n> > > > > > > > >\n> > > > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > > > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > > > > > > > > #if !INSECURE\n> > > > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3\n> > > > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)\n> > > > > > > >\n> > > > > > > > where the text is imported from another project, and we'd prefer to stay\n> > > > > > > > as close to their version as possible (e.g., to avoid unnecessary\n> > > > > > > > conflicts when pulling in new versions).\n> > > > > > >\n> > > > > > > That's fair; I wasn't aware that this was being pulled directly from\n> > > > > > > another project. I can change this back.\n> > > > > > >\n> > > > > > > >\n> > > > > > > > Also, this one should be \"effect\" anyway, as it is a noun.\n> > > > > > >\n> > > > > > > This seems to have slipped through, as I used a text search tool.\n> > > > > > >\n> > > > > > > >\n> > > > > > > > -Peff\n"},{"id":"424060","messageId":"20210510173502.GH12700@kitsune.suse.cz","threadId":"55436","inReplyTo":"CAD2i4DBSajgNFCwMMDv_tyQwuKDU095avmHs=BHcrAY1GbCqwA@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-10T17:35:02Z","receivedAt":"2021-05-10T17:35:42Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Mon, May 10, 2021 at 12:19:05PM -0500, Varun Varada wrote:\n> On Fri, 30 Apr 2021 at 02:59, Michal Suchánek wrote:\n> >\n> > On Thu, Apr 29, 2021 at 08:51:07PM -0500, Varun Varada wrote:\n> > > On Wed, 28 Apr 2021 at 13:49, Michal Suchánek wrote:\n> > > >\n> > > > On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:\n> > > > > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek wrote:\n> > > > > >\n> > > > > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:\n> > > > > > > Here's the updated diff:\n> > > > > >\n> > > > > > As already said multiple general purpose dictionaries recognize '(have)\n> > > > > > strong effect' as the meaning of 'impact', in some cases even the most\n> > > > > > common meaning.\n> > > > >\n> > > > > There's no contention here. That's the meaning I've been referring to as well.\n> > > > >\n> > > > > >\n> > > > > > In case you have some issue with the word 'jargon' Merriam-Webster gives\n> > > > > > this definition:\n> > > > > >\n> > > > > > 1: the technical terminology or characteristic idiom of a special activity or group\n> > > > > > 2: obscure and often pretentious language marked by circumlocutions and long words\n> > > > > > 3a: confused unintelligible language\n> > > > > > b: a strange, outlandish, or barbarous language or dialect\n> > > > > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech\n> > > > > >\n> > > > > > which the word 'impact' does not fulfill.\n> > > > > >\n> > > > > > Further, you would rarely discuss and document an effect that is\n> > > > > > negligible so in vast majority of cases '(have) strong effect' (ie\n> > > > > > 'impact') is synonymous to 'affect' and 'affect', respectively.\n> > > > >\n> > > > > This is not true, especially in technical contexts. \"Affect\" doesn't\n> > > > > mean \"has a slight effect on\", but simply \"has an effect on\". This\n> > > > > suffices in most cases. In cases where one would like to highlight the\n> > > > > overwhelming/awesome/debilitating/marked/strong effect that something\n> > > > > has, \"impact\" can be used. To say that every effect is overwhelming or\n> > > > > strong is jargon.\n> > > > >\n> > > > > >\n> > > > > > If you can pick out a few places where the use is specifically confusing\n> > > > > > then please pick out those. Wholesale replacement of one word with\n> > > > > > another synonym is not desired. It creates useless churn.\n> > > > >\n> > > > > I've actually not done a wholesale replacement blindly; the ones I\n> > > > > replaced are the places where I couldn't find any case where it is\n> > > > > referring to a \"strong/marked effect\". This is especially true in the\n> > > > > negative constructions. If you could help me find places where you\n> > > > > think the intended meaning is indeed \"a strong/marked effect\", I can\n> > > > > remove those from the changes.\n> > > >\n> > > > As already pointed out before the mere fact that the author of the text\n> > > > bothered to document the effect ipmlies that the effect is strong/marked\n> > > > unless stated otherwise. At any rate 'strong' is always relative. Unless\n> > > > you have a specific reference of average strenth anything can be\n> > > > considered strong or weak depending on point of view.\n> > >\n> > > This doesn't seem like a plausible or strong argument given the\n> > > context of the places where I'm editing the text. Most of them are\n> > > negative constructions, where if one were to assume \"strongly affect\"\n> >\n> > That's not the case. There are some which include negation, and many\n> > that don't. I did not review all of the patch so can't really tell but\n> > it looks like the onse that include negation are a minority or about\n> > half of what you replace at best.\n> \n> There are 27 changes, 16 of which are negation. That's more than half,\n> and at least all of these need to be replaced.\n> \n> >\n> > > was intended, then that raises the question of what actual effect it\n> > > will have. The only convincing example of this I can see is the one\n> > > where it reads \"which are tight with memory might be badly impacted by\n> > > this though\". All of the other ones seem like they're binary in\n> > > whether they will have an effect at all or no, not graduated in terms\n> > > of the degree of the effect it will have.\n> >\n> > Which also means that the distinction between 'strong effect' and\n> > 'effect' is meaningless, and 'affect' vs 'impact' is synonymous.\n> > Replacing one with the other is useless churn then.\n> \n> I'm not sure I understand what you mean by \"churn\". No one would stop\n> using Git because of these single-word changes.\n\nIt refers to redundant changes to the codebase which do not improve it in\nany way.\n\n> \n> As for there being no distinction, there's no gradation within the\n> semantics of this context; this doesn't change the semantics of the\n> words themselves. Using \"impact\" when what is meant is just \"effect\"\n> or \"affect\" is incorrect in all such instances.\n\nThat's your opinion not shared by the authors of the text.\n\nThe authority you refer to is MIT which is known for technical\nbrilliance but not as authority on linguistics.\n\n> \n> >\n> > Also the cases I saw do not really look confusing in any way so the\n> > change does not improve the documentation in any way.\n> \n> Saying \"will not impact\" means \"will not strongly affect\", as you've\n> already agreed. This necessarily means it might affect it, albeit not\n> strongly.\n\nOr not at all.\n\n> This is confusing to anyone reading the documentation, and\n\nWhen the distinction is not meaningful it is not really confusing in\nthis use, either.\n\n> is entirely unnecessary.\n\nAlso you did not limit your patch to these cases that you say are\nconfusing.\n\n> I don't understand the resistance here for\n> simple one-word changes that remove this confusion. Am I missing\n> something?\n\nThere does not seem to be any confusion to remove, at least you have not\npointed out any specific case that is particularly confusing.\n\nIf you do wholesale word replacement in the project for no good reason\nit only makes working with the project history harder.\n\nThanks\n\nMichal\n\n> \n> >\n> > >\n> > > >\n> > > > >\n> > > > > >\n> > > > > > You could make a case that 'impact' is significantly less frequent word\n> > > > > > compared to effect/affect and thus makes the text harder to understand\n> > > > > > for non-native speakers. However, that's not the point you brought up,\n> > > > > > and even then it is very weak point to make, especially without any\n> > > > > > actual source for the frequency data. You could also counter that all of\n> > > > > > these are common loanwords in many languages and are thus easy to\n> > > > > > understand to non-native speakers anyway.\n> > > > > >\n> > > > > > Thanks\n> > > > > >\n> > > > > > Michal\n> > > > > > >\n> > > > > > > Documentation/MyFirstContribution.txt | 2 +-\n> > > > > > > Documentation/MyFirstObjectWalk.txt | 2 +-\n> > > > > > > Documentation/config/pack.txt | 2 +-\n> > > > > > > Documentation/git-fast-import.txt | 14 +++++++-------\n> > > > > > > Documentation/git-fetch.txt | 2 +-\n> > > > > > > .../technical/hash-function-transition.txt | 2 +-\n> > > > > > > Documentation/user-manual.txt | 4 ++--\n> > > > > > > advice.c | 2 +-\n> > > > > > > builtin/fast-import.c | 2 +-\n> > > > > > > builtin/pack-objects.c | 2 +-\n> > > > > > > contrib/coccinelle/README | 2 +-\n> > > > > > > dir.c | 2 +-\n> > > > > > > t/perf/p5550-fetch-tags.sh | 2 +-\n> > > > > > > t/t0008-ignores.sh | 2 +-\n> > > > > > > t/t0303-credential-external.sh | 2 +-\n> > > > > > > t/t2020-checkout-detach.sh | 4 ++--\n> > > > > > > t/t4013-diff-various.sh | 2 +-\n> > > > > > > t/t5000-tar-tree.sh | 2 +-\n> > > > > > > t/test-lib-functions.sh | 2 +-\n> > > > > > > 19 files changed, 27 insertions(+), 27 deletions(-)\n> > > > > > >\n> > > > > > > diff --git a/Documentation/MyFirstContribution.txt\n> > > > > > > b/Documentation/MyFirstContribution.txt\n> > > > > > > index af0a9da62e..8372a7e59e 100644\n> > > > > > > --- a/Documentation/MyFirstContribution.txt\n> > > > > > > +++ b/Documentation/MyFirstContribution.txt\n> > > > > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> > > > > > > how to show it in the general\n> > > > > > > command list shown by `git help git` or `git help -a`, which is generated from\n> > > > > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> > > > > > > line above it in alphabetical order. Now, we can add some attributes about the\n> > > > > > > -command which impacts where it shows up in the aforementioned help\n> > > > > > > commands. The\n> > > > > > > +command which affects where it shows up in the aforementioned help\n> > > > > > > commands. The\n> > > > > > > top of `command-list.txt` shares some information about what each attribute\n> > > > > > > means; in those help pages, the commands are sorted according to these\n> > > > > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> > > > > > > diff --git a/Documentation/MyFirstObjectWalk.txt\n> > > > > > > b/Documentation/MyFirstObjectWalk.txt\n> > > > > > > index 2d10eea7a9..fd5bb8fb7d 100644\n> > > > > > > --- a/Documentation/MyFirstObjectWalk.txt\n> > > > > > > +++ b/Documentation/MyFirstObjectWalk.txt\n> > > > > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> > > > > > > By running your walk with and without the filter, you should find\n> > > > > > > that the total\n> > > > > > > object count in each case is identical. You can also time each invocation of\n> > > > > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> > > > > > > -to yourself the runtime impact of tracking all omitted objects.\n> > > > > > > +to yourself the runtime effect of tracking all omitted objects.\n> > > > > > >\n> > > > > > > === Changing the Order\n> > > > > > >\n> > > > > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> > > > > > > index 3da4ea98e2..00fcc9d7c7 100644\n> > > > > > > --- a/Documentation/config/pack.txt\n> > > > > > > +++ b/Documentation/config/pack.txt\n> > > > > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> > > > > > > This cache is used to speed up the writing object phase by not\n> > > > > > > having to recompute the final delta result once the best match\n> > > > > > > for all objects is found. Repacking large repositories on machines\n> > > > > > > - which are tight with memory might be badly impacted by this though,\n> > > > > > > + which are tight with memory might be badly affected by this though,\n> > > > > > > especially if this cache pushes the system into swapping.\n> > > > > > > A value of 0 means no limit. The smallest size of 1 byte may be\n> > > > > > > used to virtually disable this cache. Defaults to 256 MiB.\n> > > > > > > diff --git a/Documentation/git-fast-import.txt\n> > > > > > > b/Documentation/git-fast-import.txt\n> > > > > > > index 39cfa05b28..c6d8e4e1d7 100644\n> > > > > > > --- a/Documentation/git-fast-import.txt\n> > > > > > > +++ b/Documentation/git-fast-import.txt\n> > > > > > > @@ -58,7 +58,7 @@ OPTIONS\n> > > > > > > allowing fast-import to access the filesystem outside of the\n> > > > > > > repository). These options are disabled by default, but can be\n> > > > > > > allowed by providing this option on the command line. This\n> > > > > > > - currently impacts only the `export-marks`, `import-marks`, and\n> > > > > > > + currently affects only the `export-marks`, `import-marks`, and\n> > > > > > > `import-marks-if-exists` feature commands.\n> > > > > > > +\n> > > > > > > Only enable this option if you trust the program generating the\n> > > > > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> > > > > > >\n> > > > > > > A `filecopy` command takes effect immediately. Once the source\n> > > > > > > location has been copied to the destination any future commands\n> > > > > > > -applied to the source location will not impact the destination of\n> > > > > > > +applied to the source location will not affect the destination of\n> > > > > > > the copy.\n> > > > > > >\n> > > > > > > `filerename`\n> > > > > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> > > > > > > A `filerename` command takes effect immediately. Once the source\n> > > > > > > location has been renamed to the destination any future commands\n> > > > > > > applied to the source location will create new files there and not\n> > > > > > > -impact the destination of the rename.\n> > > > > > > +affect the destination of the rename.\n> > > > > > >\n> > > > > > > Note that a `filerename` is the same as a `filecopy` followed by a\n> > > > > > > `filedelete` of the source location. There is a slight performance\n> > > > > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> > > > > > > to be required).\n> > > > > > > ~~~~~~~~~~\n> > > > > > > Causes fast-import to print the entire `progress` line unmodified to\n> > > > > > > its standard output channel (file descriptor 1) when the command is\n> > > > > > > -processed from the input stream. The command otherwise has no impact\n> > > > > > > +processed from the input stream. The command otherwise has no effect\n> > > > > > > on the current import, or on any of fast-import's internal state.\n> > > > > > >\n> > > > > > > ....\n> > > > > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> > > > > > > ~~~~~~~~~~\n> > > > > > > Causes fast-import to print the SHA-1 corresponding to a mark to\n> > > > > > > stdout or to the file descriptor previously arranged with the\n> > > > > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> > > > > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> > > > > > > current import; its purpose is to retrieve SHA-1s that later commits\n> > > > > > > might want to refer to in their commit messages.\n> > > > > > >\n> > > > > > > @@ -1050,7 +1050,7 @@ this output safely.\n> > > > > > > ~~~~~~~~~~\n> > > > > > > Causes fast-import to print a blob to a file descriptor previously\n> > > > > > > arranged with the `--cat-blob-fd` argument. The command otherwise\n> > > > > > > -has no impact on the current import; its main purpose is to\n> > > > > > > +has no effect on the current import; its main purpose is to\n> > > > > > > retrieve blobs that may be in fast-import's memory but not\n> > > > > > > accessible from the target repository.\n> > > > > > >\n> > > > > > > @@ -1366,7 +1366,7 @@ code considerably.\n> > > > > > >\n> > > > > > > The branch LRU builtin to fast-import tends to behave very well, and the\n> > > > > > > cost of activating an inactive branch is so low that bouncing around\n> > > > > > > -between branches has virtually no impact on import performance.\n> > > > > > > +between branches has virtually no effect on import performance.\n> > > > > > >\n> > > > > > > Handling Renames\n> > > > > > > ~~~~~~~~~~~~~~~~\n> > > > > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> > > > > > > index 9067c2079e..01cf3b3d16 100644\n> > > > > > > --- a/Documentation/git-fetch.txt\n> > > > > > > +++ b/Documentation/git-fetch.txt\n> > > > > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> > > > > > > If left to accumulate, these stale references might make performance\n> > > > > > > worse on big and busy repos that have a lot of branch churn, and\n> > > > > > > e.g. make the output of commands like `git branch -a --contains\n> > > > > > > -` needlessly verbose, as well as impacting anything else\n> > > > > > > +` needlessly verbose, as well as affecting anything else\n> > > > > > > that'll work with the complete set of known references.\n> > > > > > >\n> > > > > > > These remote-tracking references can be deleted as a one-off with\n> > > > > > > diff --git a/Documentation/technical/hash-function-transition.txt\n> > > > > > > b/Documentation/technical/hash-function-transition.txt\n> > > > > > > index 7c1630bf83..f4296faffc 100644\n> > > > > > > --- a/Documentation/technical/hash-function-transition.txt\n> > > > > > > +++ b/Documentation/technical/hash-function-transition.txt\n> > > > > > > @@ -42,7 +42,7 @@ mitigations.\n> > > > > > >\n> > > > > > > If SHA-1 and its variants were to be truly broken, Git's hash function\n> > > > > > > could not be considered cryptographically secure any more. This would\n> > > > > > > -impact the communication of hash values because we could not trust\n> > > > > > > +affect the communication of hash values because we could not trust\n> > > > > > > that a given hash value represented the known good version of content\n> > > > > > > that the speaker intended.\n> > > > > > >\n> > > > > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > > > > > > index fd480b8645..33c60c49d7 100644\n> > > > > > > --- a/Documentation/user-manual.txt\n> > > > > > > +++ b/Documentation/user-manual.txt\n> > > > > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> > > > > > >\n> > > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > > -state without impacting any branches by performing another switch.\n> > > > > > > +state without affecting any branches by performing another switch.\n> > > > > > >\n> > > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > > do so (now or later) by using -c with the switch command again. Example:\n> > > > > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> > > > > > > overwritten by the result of\n> > > > > > > the merge when this combining is done cleanly, or overwritten by a\n> > > > > > > half-merged results when this combining results in conflicts.\n> > > > > > > Therefore, if you have uncommitted changes touching the same files as\n> > > > > > > -the ones impacted by the merge, Git will refuse to proceed. Most of\n> > > > > > > +the ones affected by the merge, Git will refuse to proceed. Most of\n> > > > > > > the time, you will want to commit your changes before you can merge,\n> > > > > > > and if you don't, then linkgit:git-stash[1] can take these changes\n> > > > > > > away while you're doing the merge, and reapply them afterwards.\n> > > > > > > diff --git a/advice.c b/advice.c\n> > > > > > > index 164742305f..9cbbb824a9 100644\n> > > > > > > --- a/advice.c\n> > > > > > > +++ b/advice.c\n> > > > > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> > > > > > > \"\\n\"\n> > > > > > > \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> > > > > > > \"changes and commit them, and you can discard any commits you make in this\\n\"\n> > > > > > > - \"state without impacting any branches by switching back to a branch.\\n\"\n> > > > > > > + \"state without affecting any branches by switching back to a branch.\\n\"\n> > > > > > > \"\\n\"\n> > > > > > > \"If you want to create a new branch to retain commits you create, you may\\n\"\n> > > > > > > \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> > > > > > > diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> > > > > > > index 3afa81cf9a..24f362d2f4 100644\n> > > > > > > --- a/builtin/fast-import.c\n> > > > > > > +++ b/builtin/fast-import.c\n> > > > > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> > > > > > > const char *prefix)\n> > > > > > > * We don't parse most options until after we've seen the set of\n> > > > > > > * \"feature\" lines at the start of the stream (which allows the command\n> > > > > > > * line to override stream data). But we must do an early parse of any\n> > > > > > > - * command-line options that impact how we interpret the feature lines.\n> > > > > > > + * command-line options that affect how we interpret the feature lines.\n> > > > > > > */\n> > > > > > > for (i = 1; i < argc; i++) {\n> > > > > > > const char *arg = argv[i];\n> > > > > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> > > > > > > index 525c2d8552..749bbca241 100644\n> > > > > > > --- a/builtin/pack-objects.c\n> > > > > > > +++ b/builtin/pack-objects.c\n> > > > > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> > > > > > > /*\n> > > > > > > * Mark ourselves as active and see if the next step causes\n> > > > > > > * us to cycle to another active object. It's important to do\n> > > > > > > - * this _before_ we loop, because it impacts where we make the\n> > > > > > > + * this _before_ we loop, because it affects where we make the\n> > > > > > > * cut, and thus how our total_depth counter works.\n> > > > > > > * E.g., We may see a partial loop like:\n> > > > > > > *\n> > > > > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> > > > > > > index f0e80bd7f0..92979ec770 100644\n> > > > > > > --- a/contrib/coccinelle/README\n> > > > > > > +++ b/contrib/coccinelle/README\n> > > > > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> > > > > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> > > > > > >\n> > > > > > > This allows to expose plans of pending large scale refactorings without\n> > > > > > > - impacting the bad pattern checks.\n> > > > > > > + affecting the bad pattern checks.\n> > > > > > > diff --git a/dir.c b/dir.c\n> > > > > > > index 3474e67e8f..235e26a90e 100644\n> > > > > > > --- a/dir.c\n> > > > > > > +++ b/dir.c\n> > > > > > > @@ -2144,7 +2144,7 @@ static enum path_treatment\n> > > > > > > treat_path_fast(struct dir_struct *dir,\n> > > > > > > /*\n> > > > > > > * We get path_recurse in the first run when\n> > > > > > > * directory_exists_in_index() returns index_nonexistent. We\n> > > > > > > - * are sure that new changes in the index does not impact the\n> > > > > > > + * are sure that new changes in the index does not affect the\n> > > > > > > * outcome. Return now.\n> > > > > > > */\n> > > > > > > return path_recurse;\n> > > > > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> > > > > > > index d0e0e019ea..1fcb98443c 100755\n> > > > > > > --- a/t/perf/p5550-fetch-tags.sh\n> > > > > > > +++ b/t/perf/p5550-fetch-tags.sh\n> > > > > > > @@ -8,7 +8,7 @@ follows.\n> > > > > > >\n> > > > > > > The parent repository has a large number of tags which are disconnected from\n> > > > > > > the rest of history. That makes them candidates for tag-following, but we never\n> > > > > > > -actually grab them (and thus they will impact each subsequent fetch).\n> > > > > > > +actually grab them (and thus they will affect each subsequent fetch).\n> > > > > > >\n> > > > > > > The child repository is a clone of parent, without the tags, and is at least\n> > > > > > > one commit behind the parent (meaning that we will fetch one object and then\n> > > > > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> > > > > > > index a594b4aa7d..95daba4000 100755\n> > > > > > > --- a/t/t0008-ignores.sh\n> > > > > > > +++ b/t/t0008-ignores.sh\n> > > > > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> > > > > > > # test standard ignores\n> > > > > > >\n> > > > > > > # First make sure that the presence of a file in the working tree\n> > > > > > > -# does not impact results, but that the presence of a file in the\n> > > > > > > +# does not affect results, but that the presence of a file in the\n> > > > > > > # index does unless the --no-index option is used.\n> > > > > > >\n> > > > > > > for subdir in '' 'a/'\n> > > > > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> > > > > > > index f028fd1418..a9348f655a 100755\n> > > > > > > --- a/t/t0303-credential-external.sh\n> > > > > > > +++ b/t/t0303-credential-external.sh\n> > > > > > > @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> > > > > > > eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> > > > > > >\n> > > > > > > # clean before the test in case there is cruft left\n> > > > > > > -# over from a previous run that would impact results\n> > > > > > > +# over from a previous run that would affect results\n> > > > > > > helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > > > > >\n> > > > > > > helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > > > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> > > > > > > index bc46713a43..568c258c5a 100755\n> > > > > > > --- a/t/t2020-checkout-detach.sh\n> > > > > > > +++ b/t/t2020-checkout-detach.sh\n> > > > > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> > > > > > > no SHA-1 ellipsis when not as\n> > > > > > >\n> > > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > > - state without impacting any branches by switching back to a branch.\n> > > > > > > + state without affecting any branches by switching back to a branch.\n> > > > > > >\n> > > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > > do so (now or later) by using -c with the switch command. Example:\n> > > > > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> > > > > > > print SHA-1 ellipsis when asked\n> > > > > > >\n> > > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > > - state without impacting any branches by switching back to a branch.\n> > > > > > > + state without affecting any branches by switching back to a branch.\n> > > > > > >\n> > > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > > do so (now or later) by using -c with the switch command. Example:\n> > > > > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> > > > > > > index 6cca8b84a6..97365a7786 100755\n> > > > > > > --- a/t/t4013-diff-various.sh\n> > > > > > > +++ b/t/t4013-diff-various.sh\n> > > > > > > @@ -109,7 +109,7 @@ test_expect_success setup '\n> > > > > > > git checkout -f master &&\n> > > > > > >\n> > > > > > > # Same merge as master, but with parents reversed. Hide it in a\n> > > > > > > - # pseudo-ref to avoid impacting tests with --all.\n> > > > > > > + # pseudo-ref to avoid affecting tests with --all.\n> > > > > > > commit=$(echo reverse |\n> > > > > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> > > > > > > git update-ref REVERSE $commit &&\n> > > > > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> > > > > > > index 7204799a0b..33a6efce2f 100755\n> > > > > > > --- a/t/t5000-tar-tree.sh\n> > > > > > > +++ b/t/t5000-tar-tree.sh\n> > > > > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> > > > > > > # Pull the size and date of each entry in a tarfile using the system tar.\n> > > > > > > #\n> > > > > > > # We'll pull out only the year from the date; that avoids any question of\n> > > > > > > -# timezones impacting the result (as long as we keep our test times away from a\n> > > > > > > +# timezones affecting the result (as long as we keep our test times away from a\n> > > > > > > # year boundary; our reference times are all in August).\n> > > > > > > #\n> > > > > > > # The output of tar_info is expected to be \" \", both in decimal. It\n> > > > > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> > > > > > > index 6348e8d733..ff65f86f50 100644\n> > > > > > > --- a/t/test-lib-functions.sh\n> > > > > > > +++ b/t/test-lib-functions.sh\n> > > > > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> > > > > > > }\n> > > > > > >\n> > > > > > > # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> > > > > > > -# it also works for shell functions (though those functions cannot impact\n> > > > > > > +# it also works for shell functions (though those functions cannot affect\n> > > > > > > # the environment outside of the test_env invocation).\n> > > > > > > test_env () {\n> > > > > > > (\n> > > > > > > --\n> > > > > > > 2.17.1\n> > > > > > >\n> > > > > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada wrote:\n> > > > > > > >\n> > > > > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King wrote:\n> > > > > > > > >\n> > > > > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n> > > > > > > > >\n> > > > > > > > > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > > > > > > > > problem the word \"impact\" in itself is not \"jargon\".\n> > > > > > > > > >\n> > > > > > > > > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > > > > > > > > strong or market influence\" (n.) when used figuratively; it is not\n> > > > > > > > > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > > > > > > > > all of the entries you've cited. Using it as such is the incorrect\n> > > > > > > > > > part, so those are the instances I've changed in the diff.\n> > > > > > > > >\n> > > > > > > > > Er, is that true? From Michal's definitions:\n> > > > > > > > >\n> > > > > > > > > > > From The Collaborative International Dictionary of English v.0.48 :\n> > > > > > > > > > [...]\n> > > > > > > > > > > 2. To affect or influence, especially in a significant or\n> > > > > > > > >\n> > > > > > > > > It literally uses \"affect\" to define it. The \"especially significant\"\n> > > > > > > > > does not apply to many, but I don't think that makes it necessarily\n> > > > > > > > > wrong to use impact to mean \"affect\".\n> > > > > > > >\n> > > > > > > > I was drawing attention to the \"especially significant\" bit and the\n> > > > > > > > like being there in all the entries. I'm not sure about these\n> > > > > > > > dictionaries, but the definition is hyperbolic / violent / shocking in\n> > > > > > > > every reputable dictionary out there: the Oxford English Dictionary,\n> > > > > > > > Merriam-Webster, and Collins.\n> > > > > > > >\n> > > > > > > > >\n> > > > > > > > > Likewise:\n> > > > > > > > >\n> > > > > > > > > > > From WordNet (r) 3.0 (2006) :\n> > > > > > > > > > [...]\n> > > > > > > > > > > v 1: press or wedge together; pack together\n> > > > > > > > > > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > > > > > > > > > affect, impact, bear upon, bear on, touch on,\n> > > > > > > > > > > touch]\n> > > > > > > > >\n> > > > > > > > > That is likewise listing \"impact\" and \"affect\" as synonyms.\n> > > > > > > > >\n> > > > > > > > > I do agree the word is over-used in some forms of writing, but I don't\n> > > > > > > > > find anything at all confusing or wrong about the uses that you changed\n> > > > > > > > > in your patch. I am a native speaker of English. I'm open to the\n> > > > > > > > > argument that non-native speakers may be more confused by the word. But\n> > > > > > > > > this seems like mostly a style preference thing, and I'd generally\n> > > > > > > > > prefer to leave the contributions and style of the original writers\n> > > > > > > > > intact unless there is a good reason not to.\n> > > > > > > >\n> > > > > > > > I am a native English speaker as well, and there were multiple places\n> > > > > > > > where I had to think twice about what the sentences mean. I agree with\n> > > > > > > > your sentiment about leaving stylistic preferences intact, but this is\n> > > > > > > > actually a semantic one. And given that there is a perfectly good\n> > > > > > > > alternative that doesn't have this confusion / jargon status, I wanted\n> > > > > > > > to make the change to improve it, especially where it says that in the\n> > > > > > > > output of the git command (`git checkout` when in detached HEAD mode).\n> > > > > > > >\n> > > > > > > > >\n> > > > > > > > > Such changes are doubly unwanted in cases like this:\n> > > > > > > > >\n> > > > > > > > > > --- a/compat/nedmalloc/malloc.c.h\n> > > > > > > > > > +++ b/compat/nedmalloc/malloc.c.h\n> > > > > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > > > > > > > > > #endif /* (FOOTERS && !INSECURE) */\n> > > > > > > > > >\n> > > > > > > > > >\n> > > > > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > > > > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > > > > > > > > > #if !INSECURE\n> > > > > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3\n> > > > > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)\n> > > > > > > > >\n> > > > > > > > > where the text is imported from another project, and we'd prefer to stay\n> > > > > > > > > as close to their version as possible (e.g., to avoid unnecessary\n> > > > > > > > > conflicts when pulling in new versions).\n> > > > > > > >\n> > > > > > > > That's fair; I wasn't aware that this was being pulled directly from\n> > > > > > > > another project. I can change this back.\n> > > > > > > >\n> > > > > > > > >\n> > > > > > > > > Also, this one should be \"effect\" anyway, as it is a noun.\n> > > > > > > >\n> > > > > > > > This seems to have slipped through, as I used a text search tool.\n> > > > > > > >\n> > > > > > > > >\n> > > > > > > > > -Peff\n"},{"id":"424067","messageId":"CAD2i4DBrERhtE5Br22s-bSt7C3SAvcHG62EZ=61COcnBGtUh-g@mail.gmail.com","threadId":"55436","inReplyTo":"20210510173502.GH12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-05-10T18:37:45Z","receivedAt":"2021-05-10T18:37:59Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Mon, 10 May 2021 at 12:35, Michal Suchánek wrote:\n>\n> On Mon, May 10, 2021 at 12:19:05PM -0500, Varun Varada wrote:\n> > On Fri, 30 Apr 2021 at 02:59, Michal Suchánek wrote:\n> > >\n> > > On Thu, Apr 29, 2021 at 08:51:07PM -0500, Varun Varada wrote:\n> > > > On Wed, 28 Apr 2021 at 13:49, Michal Suchánek wrote:\n> > > > >\n> > > > > On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:\n> > > > > > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek wrote:\n> > > > > > >\n> > > > > > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:\n> > > > > > > > Here's the updated diff:\n> > > > > > >\n> > > > > > > As already said multiple general purpose dictionaries recognize '(have)\n> > > > > > > strong effect' as the meaning of 'impact', in some cases even the most\n> > > > > > > common meaning.\n> > > > > >\n> > > > > > There's no contention here. That's the meaning I've been referring to as well.\n> > > > > >\n> > > > > > >\n> > > > > > > In case you have some issue with the word 'jargon' Merriam-Webster gives\n> > > > > > > this definition:\n> > > > > > >\n> > > > > > > 1: the technical terminology or characteristic idiom of a special activity or group\n> > > > > > > 2: obscure and often pretentious language marked by circumlocutions and long words\n> > > > > > > 3a: confused unintelligible language\n> > > > > > > b: a strange, outlandish, or barbarous language or dialect\n> > > > > > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech\n> > > > > > >\n> > > > > > > which the word 'impact' does not fulfill.\n> > > > > > >\n> > > > > > > Further, you would rarely discuss and document an effect that is\n> > > > > > > negligible so in vast majority of cases '(have) strong effect' (ie\n> > > > > > > 'impact') is synonymous to 'affect' and 'affect', respectively.\n> > > > > >\n> > > > > > This is not true, especially in technical contexts. \"Affect\" doesn't\n> > > > > > mean \"has a slight effect on\", but simply \"has an effect on\". This\n> > > > > > suffices in most cases. In cases where one would like to highlight the\n> > > > > > overwhelming/awesome/debilitating/marked/strong effect that something\n> > > > > > has, \"impact\" can be used. To say that every effect is overwhelming or\n> > > > > > strong is jargon.\n> > > > > >\n> > > > > > >\n> > > > > > > If you can pick out a few places where the use is specifically confusing\n> > > > > > > then please pick out those. Wholesale replacement of one word with\n> > > > > > > another synonym is not desired. It creates useless churn.\n> > > > > >\n> > > > > > I've actually not done a wholesale replacement blindly; the ones I\n> > > > > > replaced are the places where I couldn't find any case where it is\n> > > > > > referring to a \"strong/marked effect\". This is especially true in the\n> > > > > > negative constructions. If you could help me find places where you\n> > > > > > think the intended meaning is indeed \"a strong/marked effect\", I can\n> > > > > > remove those from the changes.\n> > > > >\n> > > > > As already pointed out before the mere fact that the author of the text\n> > > > > bothered to document the effect ipmlies that the effect is strong/marked\n> > > > > unless stated otherwise. At any rate 'strong' is always relative. Unless\n> > > > > you have a specific reference of average strenth anything can be\n> > > > > considered strong or weak depending on point of view.\n> > > >\n> > > > This doesn't seem like a plausible or strong argument given the\n> > > > context of the places where I'm editing the text. Most of them are\n> > > > negative constructions, where if one were to assume \"strongly affect\"\n> > >\n> > > That's not the case. There are some which include negation, and many\n> > > that don't. I did not review all of the patch so can't really tell but\n> > > it looks like the onse that include negation are a minority or about\n> > > half of what you replace at best.\n> >\n> > There are 27 changes, 16 of which are negation. That's more than half,\n> > and at least all of these need to be replaced.\n> >\n> > >\n> > > > was intended, then that raises the question of what actual effect it\n> > > > will have. The only convincing example of this I can see is the one\n> > > > where it reads \"which are tight with memory might be badly impacted by\n> > > > this though\". All of the other ones seem like they're binary in\n> > > > whether they will have an effect at all or no, not graduated in terms\n> > > > of the degree of the effect it will have.\n> > >\n> > > Which also means that the distinction between 'strong effect' and\n> > > 'effect' is meaningless, and 'affect' vs 'impact' is synonymous.\n> > > Replacing one with the other is useless churn then.\n> >\n> > I'm not sure I understand what you mean by \"churn\". No one would stop\n> > using Git because of these single-word changes.\n>\n> It refers to redundant changes to the codebase which do not improve it in\n> any way.\n\nI see. These changes remove the confusion about what the words mean,\nso they are not changes for the sake of changes.\n\n>\n> >\n> > As for there being no distinction, there's no gradation within the\n> > semantics of this context; this doesn't change the semantics of the\n> > words themselves. Using \"impact\" when what is meant is just \"effect\"\n> > or \"affect\" is incorrect in all such instances.\n>\n> That's your opinion not shared by the authors of the text.\n\nAre you referring to part about it changing the semantics of the\nwords, or that it is incorrect to use them as such? Because neither of\nthose are opinion; I've already cited sources that attest to this, and\nyou've also agreed about the meaning of the words in question.\n\nAlso, I'm getting the sense that you are one of the authors of the\ntext being changed; am I correct in presuming this?\n\n>\n> The authority you refer to is MIT which is known for technical\n> brilliance but not as authority on linguistics.\n\nI also cited the Oxford English Dictionary and the Modern Language\nAssociation (MLA), arguably *the* authorities on the English language\nthat are prevalent and popular for their guidance on usage.\n\n>\n> >\n> > >\n> > > Also the cases I saw do not really look confusing in any way so the\n> > > change does not improve the documentation in any way.\n> >\n> > Saying \"will not impact\" means \"will not strongly affect\", as you've\n> > already agreed. This necessarily means it might affect it, albeit not\n> > strongly.\n>\n> Or not at all.\n\nSure. So, which is it? And how will the reader know which it is? This\nis my point. There's absolutely no reason to have this confusion.\n\n>\n> > This is confusing to anyone reading the documentation, and\n>\n> When the distinction is not meaningful it is not really confusing in\n> this use, either.\n>\n> > is entirely unnecessary.\n>\n> Also you did not limit your patch to these cases that you say are\n> confusing.\n>\n> > I don't understand the resistance here for\n> > simple one-word changes that remove this confusion. Am I missing\n> > something?\n>\n> There does not seem to be any confusion to remove, at least you have not\n> pointed out any specific case that is particularly confusing.\n\nI've pointed out that all of the negation examples are confusing\nbecause they are ambiguous.\n\n>\n> If you do wholesale word replacement in the project for no good reason\n> it only makes working with the project history harder.\n\nI'm not sure I understand the sentiment here. As in, the Git history\nwill be polluted? Because the \"git blame\" command will only show\nchanges for the lines where I changed the single words.\n\nAnd it reduces ambiguity in the command output, let alone the\ndocumentation; it is not pointless. If it wasn't confusing enough for\na native English-speaking everyday user of Git, I wouldn't have taken\nthe time to read through all of the documentation about how to submit\npatches to Git, followed all of the procedures, learned to work with\nsome new Git commands, and actually made the changes to get all the\nway here just to make changes to the repository for the sake of it; I\npromise.\n\n>\n> Thanks\n>\n> Michal\n>\n> >\n> > >\n> > > >\n> > > > >\n> > > > > >\n> > > > > > >\n> > > > > > > You could make a case that 'impact' is significantly less frequent word\n> > > > > > > compared to effect/affect and thus makes the text harder to understand\n> > > > > > > for non-native speakers. However, that's not the point you brought up,\n> > > > > > > and even then it is very weak point to make, especially without any\n> > > > > > > actual source for the frequency data. You could also counter that all of\n> > > > > > > these are common loanwords in many languages and are thus easy to\n> > > > > > > understand to non-native speakers anyway.\n> > > > > > >\n> > > > > > > Thanks\n> > > > > > >\n> > > > > > > Michal\n> > > > > > > >\n> > > > > > > > Documentation/MyFirstContribution.txt | 2 +-\n> > > > > > > > Documentation/MyFirstObjectWalk.txt | 2 +-\n> > > > > > > > Documentation/config/pack.txt | 2 +-\n> > > > > > > > Documentation/git-fast-import.txt | 14 +++++++-------\n> > > > > > > > Documentation/git-fetch.txt | 2 +-\n> > > > > > > > .../technical/hash-function-transition.txt | 2 +-\n> > > > > > > > Documentation/user-manual.txt | 4 ++--\n> > > > > > > > advice.c | 2 +-\n> > > > > > > > builtin/fast-import.c | 2 +-\n> > > > > > > > builtin/pack-objects.c | 2 +-\n> > > > > > > > contrib/coccinelle/README | 2 +-\n> > > > > > > > dir.c | 2 +-\n> > > > > > > > t/perf/p5550-fetch-tags.sh | 2 +-\n> > > > > > > > t/t0008-ignores.sh | 2 +-\n> > > > > > > > t/t0303-credential-external.sh | 2 +-\n> > > > > > > > t/t2020-checkout-detach.sh | 4 ++--\n> > > > > > > > t/t4013-diff-various.sh | 2 +-\n> > > > > > > > t/t5000-tar-tree.sh | 2 +-\n> > > > > > > > t/test-lib-functions.sh | 2 +-\n> > > > > > > > 19 files changed, 27 insertions(+), 27 deletions(-)\n> > > > > > > >\n> > > > > > > > diff --git a/Documentation/MyFirstContribution.txt\n> > > > > > > > b/Documentation/MyFirstContribution.txt\n> > > > > > > > index af0a9da62e..8372a7e59e 100644\n> > > > > > > > --- a/Documentation/MyFirstContribution.txt\n> > > > > > > > +++ b/Documentation/MyFirstContribution.txt\n> > > > > > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> > > > > > > > how to show it in the general\n> > > > > > > > command list shown by `git help git` or `git help -a`, which is generated from\n> > > > > > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> > > > > > > > line above it in alphabetical order. Now, we can add some attributes about the\n> > > > > > > > -command which impacts where it shows up in the aforementioned help\n> > > > > > > > commands. The\n> > > > > > > > +command which affects where it shows up in the aforementioned help\n> > > > > > > > commands. The\n> > > > > > > > top of `command-list.txt` shares some information about what each attribute\n> > > > > > > > means; in those help pages, the commands are sorted according to these\n> > > > > > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> > > > > > > > diff --git a/Documentation/MyFirstObjectWalk.txt\n> > > > > > > > b/Documentation/MyFirstObjectWalk.txt\n> > > > > > > > index 2d10eea7a9..fd5bb8fb7d 100644\n> > > > > > > > --- a/Documentation/MyFirstObjectWalk.txt\n> > > > > > > > +++ b/Documentation/MyFirstObjectWalk.txt\n> > > > > > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> > > > > > > > By running your walk with and without the filter, you should find\n> > > > > > > > that the total\n> > > > > > > > object count in each case is identical. You can also time each invocation of\n> > > > > > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> > > > > > > > -to yourself the runtime impact of tracking all omitted objects.\n> > > > > > > > +to yourself the runtime effect of tracking all omitted objects.\n> > > > > > > >\n> > > > > > > > === Changing the Order\n> > > > > > > >\n> > > > > > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> > > > > > > > index 3da4ea98e2..00fcc9d7c7 100644\n> > > > > > > > --- a/Documentation/config/pack.txt\n> > > > > > > > +++ b/Documentation/config/pack.txt\n> > > > > > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> > > > > > > > This cache is used to speed up the writing object phase by not\n> > > > > > > > having to recompute the final delta result once the best match\n> > > > > > > > for all objects is found. Repacking large repositories on machines\n> > > > > > > > - which are tight with memory might be badly impacted by this though,\n> > > > > > > > + which are tight with memory might be badly affected by this though,\n> > > > > > > > especially if this cache pushes the system into swapping.\n> > > > > > > > A value of 0 means no limit. The smallest size of 1 byte may be\n> > > > > > > > used to virtually disable this cache. Defaults to 256 MiB.\n> > > > > > > > diff --git a/Documentation/git-fast-import.txt\n> > > > > > > > b/Documentation/git-fast-import.txt\n> > > > > > > > index 39cfa05b28..c6d8e4e1d7 100644\n> > > > > > > > --- a/Documentation/git-fast-import.txt\n> > > > > > > > +++ b/Documentation/git-fast-import.txt\n> > > > > > > > @@ -58,7 +58,7 @@ OPTIONS\n> > > > > > > > allowing fast-import to access the filesystem outside of the\n> > > > > > > > repository). These options are disabled by default, but can be\n> > > > > > > > allowed by providing this option on the command line. This\n> > > > > > > > - currently impacts only the `export-marks`, `import-marks`, and\n> > > > > > > > + currently affects only the `export-marks`, `import-marks`, and\n> > > > > > > > `import-marks-if-exists` feature commands.\n> > > > > > > > +\n> > > > > > > > Only enable this option if you trust the program generating the\n> > > > > > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> > > > > > > >\n> > > > > > > > A `filecopy` command takes effect immediately. Once the source\n> > > > > > > > location has been copied to the destination any future commands\n> > > > > > > > -applied to the source location will not impact the destination of\n> > > > > > > > +applied to the source location will not affect the destination of\n> > > > > > > > the copy.\n> > > > > > > >\n> > > > > > > > `filerename`\n> > > > > > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> > > > > > > > A `filerename` command takes effect immediately. Once the source\n> > > > > > > > location has been renamed to the destination any future commands\n> > > > > > > > applied to the source location will create new files there and not\n> > > > > > > > -impact the destination of the rename.\n> > > > > > > > +affect the destination of the rename.\n> > > > > > > >\n> > > > > > > > Note that a `filerename` is the same as a `filecopy` followed by a\n> > > > > > > > `filedelete` of the source location. There is a slight performance\n> > > > > > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> > > > > > > > to be required).\n> > > > > > > > ~~~~~~~~~~\n> > > > > > > > Causes fast-import to print the entire `progress` line unmodified to\n> > > > > > > > its standard output channel (file descriptor 1) when the command is\n> > > > > > > > -processed from the input stream. The command otherwise has no impact\n> > > > > > > > +processed from the input stream. The command otherwise has no effect\n> > > > > > > > on the current import, or on any of fast-import's internal state.\n> > > > > > > >\n> > > > > > > > ....\n> > > > > > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> > > > > > > > ~~~~~~~~~~\n> > > > > > > > Causes fast-import to print the SHA-1 corresponding to a mark to\n> > > > > > > > stdout or to the file descriptor previously arranged with the\n> > > > > > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> > > > > > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> > > > > > > > current import; its purpose is to retrieve SHA-1s that later commits\n> > > > > > > > might want to refer to in their commit messages.\n> > > > > > > >\n> > > > > > > > @@ -1050,7 +1050,7 @@ this output safely.\n> > > > > > > > ~~~~~~~~~~\n> > > > > > > > Causes fast-import to print a blob to a file descriptor previously\n> > > > > > > > arranged with the `--cat-blob-fd` argument. The command otherwise\n> > > > > > > > -has no impact on the current import; its main purpose is to\n> > > > > > > > +has no effect on the current import; its main purpose is to\n> > > > > > > > retrieve blobs that may be in fast-import's memory but not\n> > > > > > > > accessible from the target repository.\n> > > > > > > >\n> > > > > > > > @@ -1366,7 +1366,7 @@ code considerably.\n> > > > > > > >\n> > > > > > > > The branch LRU builtin to fast-import tends to behave very well, and the\n> > > > > > > > cost of activating an inactive branch is so low that bouncing around\n> > > > > > > > -between branches has virtually no impact on import performance.\n> > > > > > > > +between branches has virtually no effect on import performance.\n> > > > > > > >\n> > > > > > > > Handling Renames\n> > > > > > > > ~~~~~~~~~~~~~~~~\n> > > > > > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> > > > > > > > index 9067c2079e..01cf3b3d16 100644\n> > > > > > > > --- a/Documentation/git-fetch.txt\n> > > > > > > > +++ b/Documentation/git-fetch.txt\n> > > > > > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> > > > > > > > If left to accumulate, these stale references might make performance\n> > > > > > > > worse on big and busy repos that have a lot of branch churn, and\n> > > > > > > > e.g. make the output of commands like `git branch -a --contains\n> > > > > > > > -` needlessly verbose, as well as impacting anything else\n> > > > > > > > +` needlessly verbose, as well as affecting anything else\n> > > > > > > > that'll work with the complete set of known references.\n> > > > > > > >\n> > > > > > > > These remote-tracking references can be deleted as a one-off with\n> > > > > > > > diff --git a/Documentation/technical/hash-function-transition.txt\n> > > > > > > > b/Documentation/technical/hash-function-transition.txt\n> > > > > > > > index 7c1630bf83..f4296faffc 100644\n> > > > > > > > --- a/Documentation/technical/hash-function-transition.txt\n> > > > > > > > +++ b/Documentation/technical/hash-function-transition.txt\n> > > > > > > > @@ -42,7 +42,7 @@ mitigations.\n> > > > > > > >\n> > > > > > > > If SHA-1 and its variants were to be truly broken, Git's hash function\n> > > > > > > > could not be considered cryptographically secure any more. This would\n> > > > > > > > -impact the communication of hash values because we could not trust\n> > > > > > > > +affect the communication of hash values because we could not trust\n> > > > > > > > that a given hash value represented the known good version of content\n> > > > > > > > that the speaker intended.\n> > > > > > > >\n> > > > > > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > > > > > > > index fd480b8645..33c60c49d7 100644\n> > > > > > > > --- a/Documentation/user-manual.txt\n> > > > > > > > +++ b/Documentation/user-manual.txt\n> > > > > > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> > > > > > > >\n> > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > > > -state without impacting any branches by performing another switch.\n> > > > > > > > +state without affecting any branches by performing another switch.\n> > > > > > > >\n> > > > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > > > do so (now or later) by using -c with the switch command again. Example:\n> > > > > > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> > > > > > > > overwritten by the result of\n> > > > > > > > the merge when this combining is done cleanly, or overwritten by a\n> > > > > > > > half-merged results when this combining results in conflicts.\n> > > > > > > > Therefore, if you have uncommitted changes touching the same files as\n> > > > > > > > -the ones impacted by the merge, Git will refuse to proceed. Most of\n> > > > > > > > +the ones affected by the merge, Git will refuse to proceed. Most of\n> > > > > > > > the time, you will want to commit your changes before you can merge,\n> > > > > > > > and if you don't, then linkgit:git-stash[1] can take these changes\n> > > > > > > > away while you're doing the merge, and reapply them afterwards.\n> > > > > > > > diff --git a/advice.c b/advice.c\n> > > > > > > > index 164742305f..9cbbb824a9 100644\n> > > > > > > > --- a/advice.c\n> > > > > > > > +++ b/advice.c\n> > > > > > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> > > > > > > > \"\\n\"\n> > > > > > > > \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> > > > > > > > \"changes and commit them, and you can discard any commits you make in this\\n\"\n> > > > > > > > - \"state without impacting any branches by switching back to a branch.\\n\"\n> > > > > > > > + \"state without affecting any branches by switching back to a branch.\\n\"\n> > > > > > > > \"\\n\"\n> > > > > > > > \"If you want to create a new branch to retain commits you create, you may\\n\"\n> > > > > > > > \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> > > > > > > > diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> > > > > > > > index 3afa81cf9a..24f362d2f4 100644\n> > > > > > > > --- a/builtin/fast-import.c\n> > > > > > > > +++ b/builtin/fast-import.c\n> > > > > > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> > > > > > > > const char *prefix)\n> > > > > > > > * We don't parse most options until after we've seen the set of\n> > > > > > > > * \"feature\" lines at the start of the stream (which allows the command\n> > > > > > > > * line to override stream data). But we must do an early parse of any\n> > > > > > > > - * command-line options that impact how we interpret the feature lines.\n> > > > > > > > + * command-line options that affect how we interpret the feature lines.\n> > > > > > > > */\n> > > > > > > > for (i = 1; i < argc; i++) {\n> > > > > > > > const char *arg = argv[i];\n> > > > > > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> > > > > > > > index 525c2d8552..749bbca241 100644\n> > > > > > > > --- a/builtin/pack-objects.c\n> > > > > > > > +++ b/builtin/pack-objects.c\n> > > > > > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> > > > > > > > /*\n> > > > > > > > * Mark ourselves as active and see if the next step causes\n> > > > > > > > * us to cycle to another active object. It's important to do\n> > > > > > > > - * this _before_ we loop, because it impacts where we make the\n> > > > > > > > + * this _before_ we loop, because it affects where we make the\n> > > > > > > > * cut, and thus how our total_depth counter works.\n> > > > > > > > * E.g., We may see a partial loop like:\n> > > > > > > > *\n> > > > > > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> > > > > > > > index f0e80bd7f0..92979ec770 100644\n> > > > > > > > --- a/contrib/coccinelle/README\n> > > > > > > > +++ b/contrib/coccinelle/README\n> > > > > > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> > > > > > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> > > > > > > >\n> > > > > > > > This allows to expose plans of pending large scale refactorings without\n> > > > > > > > - impacting the bad pattern checks.\n> > > > > > > > + affecting the bad pattern checks.\n> > > > > > > > diff --git a/dir.c b/dir.c\n> > > > > > > > index 3474e67e8f..235e26a90e 100644\n> > > > > > > > --- a/dir.c\n> > > > > > > > +++ b/dir.c\n> > > > > > > > @@ -2144,7 +2144,7 @@ static enum path_treatment\n> > > > > > > > treat_path_fast(struct dir_struct *dir,\n> > > > > > > > /*\n> > > > > > > > * We get path_recurse in the first run when\n> > > > > > > > * directory_exists_in_index() returns index_nonexistent. We\n> > > > > > > > - * are sure that new changes in the index does not impact the\n> > > > > > > > + * are sure that new changes in the index does not affect the\n> > > > > > > > * outcome. Return now.\n> > > > > > > > */\n> > > > > > > > return path_recurse;\n> > > > > > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> > > > > > > > index d0e0e019ea..1fcb98443c 100755\n> > > > > > > > --- a/t/perf/p5550-fetch-tags.sh\n> > > > > > > > +++ b/t/perf/p5550-fetch-tags.sh\n> > > > > > > > @@ -8,7 +8,7 @@ follows.\n> > > > > > > >\n> > > > > > > > The parent repository has a large number of tags which are disconnected from\n> > > > > > > > the rest of history. That makes them candidates for tag-following, but we never\n> > > > > > > > -actually grab them (and thus they will impact each subsequent fetch).\n> > > > > > > > +actually grab them (and thus they will affect each subsequent fetch).\n> > > > > > > >\n> > > > > > > > The child repository is a clone of parent, without the tags, and is at least\n> > > > > > > > one commit behind the parent (meaning that we will fetch one object and then\n> > > > > > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> > > > > > > > index a594b4aa7d..95daba4000 100755\n> > > > > > > > --- a/t/t0008-ignores.sh\n> > > > > > > > +++ b/t/t0008-ignores.sh\n> > > > > > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> > > > > > > > # test standard ignores\n> > > > > > > >\n> > > > > > > > # First make sure that the presence of a file in the working tree\n> > > > > > > > -# does not impact results, but that the presence of a file in the\n> > > > > > > > +# does not affect results, but that the presence of a file in the\n> > > > > > > > # index does unless the --no-index option is used.\n> > > > > > > >\n> > > > > > > > for subdir in '' 'a/'\n> > > > > > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> > > > > > > > index f028fd1418..a9348f655a 100755\n> > > > > > > > --- a/t/t0303-credential-external.sh\n> > > > > > > > +++ b/t/t0303-credential-external.sh\n> > > > > > > > @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> > > > > > > > eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> > > > > > > >\n> > > > > > > > # clean before the test in case there is cruft left\n> > > > > > > > -# over from a previous run that would impact results\n> > > > > > > > +# over from a previous run that would affect results\n> > > > > > > > helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > > > > > >\n> > > > > > > > helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > > > > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> > > > > > > > index bc46713a43..568c258c5a 100755\n> > > > > > > > --- a/t/t2020-checkout-detach.sh\n> > > > > > > > +++ b/t/t2020-checkout-detach.sh\n> > > > > > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> > > > > > > > no SHA-1 ellipsis when not as\n> > > > > > > >\n> > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > > > - state without impacting any branches by switching back to a branch.\n> > > > > > > > + state without affecting any branches by switching back to a branch.\n> > > > > > > >\n> > > > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > > > do so (now or later) by using -c with the switch command. Example:\n> > > > > > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> > > > > > > > print SHA-1 ellipsis when asked\n> > > > > > > >\n> > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > > > - state without impacting any branches by switching back to a branch.\n> > > > > > > > + state without affecting any branches by switching back to a branch.\n> > > > > > > >\n> > > > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > > > do so (now or later) by using -c with the switch command. Example:\n> > > > > > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> > > > > > > > index 6cca8b84a6..97365a7786 100755\n> > > > > > > > --- a/t/t4013-diff-various.sh\n> > > > > > > > +++ b/t/t4013-diff-various.sh\n> > > > > > > > @@ -109,7 +109,7 @@ test_expect_success setup '\n> > > > > > > > git checkout -f master &&\n> > > > > > > >\n> > > > > > > > # Same merge as master, but with parents reversed. Hide it in a\n> > > > > > > > - # pseudo-ref to avoid impacting tests with --all.\n> > > > > > > > + # pseudo-ref to avoid affecting tests with --all.\n> > > > > > > > commit=$(echo reverse |\n> > > > > > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> > > > > > > > git update-ref REVERSE $commit &&\n> > > > > > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> > > > > > > > index 7204799a0b..33a6efce2f 100755\n> > > > > > > > --- a/t/t5000-tar-tree.sh\n> > > > > > > > +++ b/t/t5000-tar-tree.sh\n> > > > > > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> > > > > > > > # Pull the size and date of each entry in a tarfile using the system tar.\n> > > > > > > > #\n> > > > > > > > # We'll pull out only the year from the date; that avoids any question of\n> > > > > > > > -# timezones impacting the result (as long as we keep our test times away from a\n> > > > > > > > +# timezones affecting the result (as long as we keep our test times away from a\n> > > > > > > > # year boundary; our reference times are all in August).\n> > > > > > > > #\n> > > > > > > > # The output of tar_info is expected to be \" \", both in decimal. It\n> > > > > > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> > > > > > > > index 6348e8d733..ff65f86f50 100644\n> > > > > > > > --- a/t/test-lib-functions.sh\n> > > > > > > > +++ b/t/test-lib-functions.sh\n> > > > > > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> > > > > > > > }\n> > > > > > > >\n> > > > > > > > # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> > > > > > > > -# it also works for shell functions (though those functions cannot impact\n> > > > > > > > +# it also works for shell functions (though those functions cannot affect\n> > > > > > > > # the environment outside of the test_env invocation).\n> > > > > > > > test_env () {\n> > > > > > > > (\n> > > > > > > > --\n> > > > > > > > 2.17.1\n> > > > > > > >\n> > > > > > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada wrote:\n> > > > > > > > >\n> > > > > > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King wrote:\n> > > > > > > > > >\n> > > > > > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n> > > > > > > > > >\n> > > > > > > > > > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > > > > > > > > > problem the word \"impact\" in itself is not \"jargon\".\n> > > > > > > > > > >\n> > > > > > > > > > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > > > > > > > > > strong or market influence\" (n.) when used figuratively; it is not\n> > > > > > > > > > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > > > > > > > > > all of the entries you've cited. Using it as such is the incorrect\n> > > > > > > > > > > part, so those are the instances I've changed in the diff.\n> > > > > > > > > >\n> > > > > > > > > > Er, is that true? From Michal's definitions:\n> > > > > > > > > >\n> > > > > > > > > > > > From The Collaborative International Dictionary of English v.0.48 :\n> > > > > > > > > > > [...]\n> > > > > > > > > > > > 2. To affect or influence, especially in a significant or\n> > > > > > > > > >\n> > > > > > > > > > It literally uses \"affect\" to define it. The \"especially significant\"\n> > > > > > > > > > does not apply to many, but I don't think that makes it necessarily\n> > > > > > > > > > wrong to use impact to mean \"affect\".\n> > > > > > > > >\n> > > > > > > > > I was drawing attention to the \"especially significant\" bit and the\n> > > > > > > > > like being there in all the entries. I'm not sure about these\n> > > > > > > > > dictionaries, but the definition is hyperbolic / violent / shocking in\n> > > > > > > > > every reputable dictionary out there: the Oxford English Dictionary,\n> > > > > > > > > Merriam-Webster, and Collins.\n> > > > > > > > >\n> > > > > > > > > >\n> > > > > > > > > > Likewise:\n> > > > > > > > > >\n> > > > > > > > > > > > From WordNet (r) 3.0 (2006) :\n> > > > > > > > > > > [...]\n> > > > > > > > > > > > v 1: press or wedge together; pack together\n> > > > > > > > > > > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > > > > > > > > > > affect, impact, bear upon, bear on, touch on,\n> > > > > > > > > > > > touch]\n> > > > > > > > > >\n> > > > > > > > > > That is likewise listing \"impact\" and \"affect\" as synonyms.\n> > > > > > > > > >\n> > > > > > > > > > I do agree the word is over-used in some forms of writing, but I don't\n> > > > > > > > > > find anything at all confusing or wrong about the uses that you changed\n> > > > > > > > > > in your patch. I am a native speaker of English. I'm open to the\n> > > > > > > > > > argument that non-native speakers may be more confused by the word. But\n> > > > > > > > > > this seems like mostly a style preference thing, and I'd generally\n> > > > > > > > > > prefer to leave the contributions and style of the original writers\n> > > > > > > > > > intact unless there is a good reason not to.\n> > > > > > > > >\n> > > > > > > > > I am a native English speaker as well, and there were multiple places\n> > > > > > > > > where I had to think twice about what the sentences mean. I agree with\n> > > > > > > > > your sentiment about leaving stylistic preferences intact, but this is\n> > > > > > > > > actually a semantic one. And given that there is a perfectly good\n> > > > > > > > > alternative that doesn't have this confusion / jargon status, I wanted\n> > > > > > > > > to make the change to improve it, especially where it says that in the\n> > > > > > > > > output of the git command (`git checkout` when in detached HEAD mode).\n> > > > > > > > >\n> > > > > > > > > >\n> > > > > > > > > > Such changes are doubly unwanted in cases like this:\n> > > > > > > > > >\n> > > > > > > > > > > --- a/compat/nedmalloc/malloc.c.h\n> > > > > > > > > > > +++ b/compat/nedmalloc/malloc.c.h\n> > > > > > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > > > > > > > > > > #endif /* (FOOTERS && !INSECURE) */\n> > > > > > > > > > >\n> > > > > > > > > > >\n> > > > > > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > > > > > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > > > > > > > > > > #if !INSECURE\n> > > > > > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3\n> > > > > > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)\n> > > > > > > > > >\n> > > > > > > > > > where the text is imported from another project, and we'd prefer to stay\n> > > > > > > > > > as close to their version as possible (e.g., to avoid unnecessary\n> > > > > > > > > > conflicts when pulling in new versions).\n> > > > > > > > >\n> > > > > > > > > That's fair; I wasn't aware that this was being pulled directly from\n> > > > > > > > > another project. I can change this back.\n> > > > > > > > >\n> > > > > > > > > >\n> > > > > > > > > > Also, this one should be \"effect\" anyway, as it is a noun.\n> > > > > > > > >\n> > > > > > > > > This seems to have slipped through, as I used a text search tool.\n> > > > > > > > >\n> > > > > > > > > >\n> > > > > > > > > > -Peff\n"},{"id":"424121","messageId":"20210511104326.GJ12700@kitsune.suse.cz","threadId":"55436","inReplyTo":"CAD2i4DBrERhtE5Br22s-bSt7C3SAvcHG62EZ=61COcnBGtUh-g@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-11T10:43:26Z","receivedAt":"2021-05-11T10:43:33Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Mon, May 10, 2021 at 01:37:45PM -0500, Varun Varada wrote:\n> On Mon, 10 May 2021 at 12:35, Michal Suchánek wrote:\n> >\n> > On Mon, May 10, 2021 at 12:19:05PM -0500, Varun Varada wrote:\n> > > On Fri, 30 Apr 2021 at 02:59, Michal Suchánek wrote:\n> > > >\n> > > > On Thu, Apr 29, 2021 at 08:51:07PM -0500, Varun Varada wrote:\n> > > > > On Wed, 28 Apr 2021 at 13:49, Michal Suchánek wrote:\n> > > > > >\n> > > > > > On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:\n> > > > > > > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek wrote:\n> > > > > > > >\n> > > > > > > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:\n> > > > > > > > > Here's the updated diff:\n> > > > > > > >\n> > > > > > > > As already said multiple general purpose dictionaries recognize '(have)\n> > > > > > > > strong effect' as the meaning of 'impact', in some cases even the most\n> > > > > > > > common meaning.\n> > > > > > >\n> > > > > > > There's no contention here. That's the meaning I've been referring to as well.\n> > > > > > >\n> > > > > > > >\n> > > > > > > > In case you have some issue with the word 'jargon' Merriam-Webster gives\n> > > > > > > > this definition:\n> > > > > > > >\n> > > > > > > > 1: the technical terminology or characteristic idiom of a special activity or group\n> > > > > > > > 2: obscure and often pretentious language marked by circumlocutions and long words\n> > > > > > > > 3a: confused unintelligible language\n> > > > > > > > b: a strange, outlandish, or barbarous language or dialect\n> > > > > > > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech\n> > > > > > > >\n> > > > > > > > which the word 'impact' does not fulfill.\n> > > > > > > >\n> > > > > > > > Further, you would rarely discuss and document an effect that is\n> > > > > > > > negligible so in vast majority of cases '(have) strong effect' (ie\n> > > > > > > > 'impact') is synonymous to 'affect' and 'affect', respectively.\n> > > > > > >\n> > > > > > > This is not true, especially in technical contexts. \"Affect\" doesn't\n> > > > > > > mean \"has a slight effect on\", but simply \"has an effect on\". This\n> > > > > > > suffices in most cases. In cases where one would like to highlight the\n> > > > > > > overwhelming/awesome/debilitating/marked/strong effect that something\n> > > > > > > has, \"impact\" can be used. To say that every effect is overwhelming or\n> > > > > > > strong is jargon.\n> > > > > > >\n> > > > > > > >\n> > > > > > > > If you can pick out a few places where the use is specifically confusing\n> > > > > > > > then please pick out those. Wholesale replacement of one word with\n> > > > > > > > another synonym is not desired. It creates useless churn.\n> > > > > > >\n> > > > > > > I've actually not done a wholesale replacement blindly; the ones I\n> > > > > > > replaced are the places where I couldn't find any case where it is\n> > > > > > > referring to a \"strong/marked effect\". This is especially true in the\n> > > > > > > negative constructions. If you could help me find places where you\n> > > > > > > think the intended meaning is indeed \"a strong/marked effect\", I can\n> > > > > > > remove those from the changes.\n> > > > > >\n> > > > > > As already pointed out before the mere fact that the author of the text\n> > > > > > bothered to document the effect ipmlies that the effect is strong/marked\n> > > > > > unless stated otherwise. At any rate 'strong' is always relative. Unless\n> > > > > > you have a specific reference of average strenth anything can be\n> > > > > > considered strong or weak depending on point of view.\n> > > > >\n> > > > > This doesn't seem like a plausible or strong argument given the\n> > > > > context of the places where I'm editing the text. Most of them are\n> > > > > negative constructions, where if one were to assume \"strongly affect\"\n> > > >\n> > > > That's not the case. There are some which include negation, and many\n> > > > that don't. I did not review all of the patch so can't really tell but\n> > > > it looks like the onse that include negation are a minority or about\n> > > > half of what you replace at best.\n> > >\n> > > There are 27 changes, 16 of which are negation. That's more than half,\n> > > and at least all of these need to be replaced.\n> > >\n> > > >\n> > > > > was intended, then that raises the question of what actual effect it\n> > > > > will have. The only convincing example of this I can see is the one\n> > > > > where it reads \"which are tight with memory might be badly impacted by\n> > > > > this though\". All of the other ones seem like they're binary in\n> > > > > whether they will have an effect at all or no, not graduated in terms\n> > > > > of the degree of the effect it will have.\n> > > >\n> > > > Which also means that the distinction between 'strong effect' and\n> > > > 'effect' is meaningless, and 'affect' vs 'impact' is synonymous.\n> > > > Replacing one with the other is useless churn then.\n> > >\n> > > I'm not sure I understand what you mean by \"churn\". No one would stop\n> > > using Git because of these single-word changes.\n> >\n> > It refers to redundant changes to the codebase which do not improve it in\n> > any way.\n> \n> I see. These changes remove the confusion about what the words mean,\n> so they are not changes for the sake of changes.\n> \n> >\n> > >\n> > > As for there being no distinction, there's no gradation within the\n> > > semantics of this context; this doesn't change the semantics of the\n> > > words themselves. Using \"impact\" when what is meant is just \"effect\"\n> > > or \"affect\" is incorrect in all such instances.\n> >\n> > That's your opinion not shared by the authors of the text.\n> \n> Are you referring to part about it changing the semantics of the\n> words, or that it is incorrect to use them as such? Because neither of\n> those are opinion; I've already cited sources that attest to this, and\n> you've also agreed about the meaning of the words in question.\n> > > already agreed. This necessarily means it might affect it, albeit not\n> > > strongly.\n> >\n> > Or not at all.\n> \n> Sure. So, which is it? And how will the reader know which it is? This\n> is my point. There's absolutely no reason to have this confusion.\n> \n> Also, I'm getting the sense that you are one of the authors of the\n> text being changed; am I correct in presuming this?\nNo, I am not.\n> \n> >\n> > The authority you refer to is MIT which is known for technical\n> > brilliance but not as authority on linguistics.\n> \n> I also cited the Oxford English Dictionary and the Modern Language\n> Association (MLA), arguably *the* authorities on the English language\n> that are prevalent and popular for their guidance on usage.\n\nThe dictionaries define 'impact' as '(having) strong effect'. They do\nnot define when it is appropriate to use the word 'impact'.\n\nWith the tendency of at least some English speakers to use superlatives\nneedlessly the use of 'impact' as synonym for affect/effect is not\nsurprising.\n\nAlso there is no single authority on the English language. The language\nis spoken in multiple distinct countries, and even within one country\nthere is some variation. It also evolves over time.\n\nSince you can look up the meaning of the word in a general purpose\ndictionary it should be an acceptable use even if it's less commonly\nused in some other English-speaking parts of the world.\n\n> \n> >\n> > >\n> > > >\n> > > > Also the cases I saw do not really look confusing in any way so the\n> > > > change does not improve the documentation in any way.\n> > >\n> > > Saying \"will not impact\" means \"will not strongly affect\", as you've\n> \n> >\n> > > This is confusing to anyone reading the documentation, and\n> >\n> > When the distinction is not meaningful it is not really confusing in\n> > this use, either.\n> >\n> > > is entirely unnecessary.\n> >\n> > Also you did not limit your patch to these cases that you say are\n> > confusing.\n> >\n> > > I don't understand the resistance here for\n> > > simple one-word changes that remove this confusion. Am I missing\n> > > something?\n> >\n> > There does not seem to be any confusion to remove, at least you have not\n> > pointed out any specific case that is particularly confusing.\n> \n> I've pointed out that all of the negation examples are confusing\n> because they are ambiguous.\n\nThey are not confusing in the way they are used. That is 'does not\nimpact' in the maning 'has no or negligible effect', and especially in\nthe cases where the degree of effect is not considered and only there\nbeing an effect or not is discussed there is no room for confusion.\n\n> \n> >\n> > If you do wholesale word replacement in the project for no good reason\n> > it only makes working with the project history harder.\n> \n> I'm not sure I understand the sentiment here. As in, the Git history\n> will be polluted? Because the \"git blame\" command will only show\n> changes for the lines where I changed the single words.\n\nYes, it will be polluted. And since we have an opinion of another native\nEnglish speaker that the use of 'impact' as synonym for affect/effect is\nfine this is clearly a matter of opinion.\n\nAlso we have the opinion of the author of the text that such use is fine\nwhich is the most relevant unless solid evidence is provided that such\nuse is indeed wrong and/or generally impedes understanding of the text.\n\nClearly even a native speakers of a language can be sometimes confused\nby one word or another, and unless it is shown to be a general problem\nwe would get into a back and forth replacing words with another synonym\nthat somebody happens to find less confusing.\n\nAn interesting case of this is when correctors that come from different\nplaces change a line back and forth because in the place where they come\nfrom one word (order) is more common and sounds more natural than the\nother.\n\nThis topic somewhat interests me so I was continuing this discussion\nin the hope that you either provide a specific very confusing use of the\nword impact in the documentation that triggered creating this patch or\nsome solid evidence that the general use of word 'impact' as synonym for\naffect/effect is in some way problematic but niether happened.\n\nI think this topic has been discussed sufficiently and there is nothing\nmore to add.\n\nThanks\n\nMichal\n> \n> And it reduces ambiguity in the command output, let alone the\n> documentation; it is not pointless. If it wasn't confusing enough for\n> a native English-speaking everyday user of Git, I wouldn't have taken\n> the time to read through all of the documentation about how to submit\n> patches to Git, followed all of the procedures, learned to work with\n> some new Git commands, and actually made the changes to get all the\n> way here just to make changes to the repository for the sake of it; I\n> promise.\n> \n> >\n> > Thanks\n> >\n> > Michal\n> >\n> > >\n> > > >\n> > > > >\n> > > > > >\n> > > > > > >\n> > > > > > > >\n> > > > > > > > You could make a case that 'impact' is significantly less frequent word\n> > > > > > > > compared to effect/affect and thus makes the text harder to understand\n> > > > > > > > for non-native speakers. However, that's not the point you brought up,\n> > > > > > > > and even then it is very weak point to make, especially without any\n> > > > > > > > actual source for the frequency data. You could also counter that all of\n> > > > > > > > these are common loanwords in many languages and are thus easy to\n> > > > > > > > understand to non-native speakers anyway.\n> > > > > > > >\n> > > > > > > > Thanks\n> > > > > > > >\n> > > > > > > > Michal\n> > > > > > > > >\n> > > > > > > > > Documentation/MyFirstContribution.txt | 2 +-\n> > > > > > > > > Documentation/MyFirstObjectWalk.txt | 2 +-\n> > > > > > > > > Documentation/config/pack.txt | 2 +-\n> > > > > > > > > Documentation/git-fast-import.txt | 14 +++++++-------\n> > > > > > > > > Documentation/git-fetch.txt | 2 +-\n> > > > > > > > > .../technical/hash-function-transition.txt | 2 +-\n> > > > > > > > > Documentation/user-manual.txt | 4 ++--\n> > > > > > > > > advice.c | 2 +-\n> > > > > > > > > builtin/fast-import.c | 2 +-\n> > > > > > > > > builtin/pack-objects.c | 2 +-\n> > > > > > > > > contrib/coccinelle/README | 2 +-\n> > > > > > > > > dir.c | 2 +-\n> > > > > > > > > t/perf/p5550-fetch-tags.sh | 2 +-\n> > > > > > > > > t/t0008-ignores.sh | 2 +-\n> > > > > > > > > t/t0303-credential-external.sh | 2 +-\n> > > > > > > > > t/t2020-checkout-detach.sh | 4 ++--\n> > > > > > > > > t/t4013-diff-various.sh | 2 +-\n> > > > > > > > > t/t5000-tar-tree.sh | 2 +-\n> > > > > > > > > t/test-lib-functions.sh | 2 +-\n> > > > > > > > > 19 files changed, 27 insertions(+), 27 deletions(-)\n> > > > > > > > >\n> > > > > > > > > diff --git a/Documentation/MyFirstContribution.txt\n> > > > > > > > > b/Documentation/MyFirstContribution.txt\n> > > > > > > > > index af0a9da62e..8372a7e59e 100644\n> > > > > > > > > --- a/Documentation/MyFirstContribution.txt\n> > > > > > > > > +++ b/Documentation/MyFirstContribution.txt\n> > > > > > > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> > > > > > > > > how to show it in the general\n> > > > > > > > > command list shown by `git help git` or `git help -a`, which is generated from\n> > > > > > > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> > > > > > > > > line above it in alphabetical order. Now, we can add some attributes about the\n> > > > > > > > > -command which impacts where it shows up in the aforementioned help\n> > > > > > > > > commands. The\n> > > > > > > > > +command which affects where it shows up in the aforementioned help\n> > > > > > > > > commands. The\n> > > > > > > > > top of `command-list.txt` shares some information about what each attribute\n> > > > > > > > > means; in those help pages, the commands are sorted according to these\n> > > > > > > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> > > > > > > > > diff --git a/Documentation/MyFirstObjectWalk.txt\n> > > > > > > > > b/Documentation/MyFirstObjectWalk.txt\n> > > > > > > > > index 2d10eea7a9..fd5bb8fb7d 100644\n> > > > > > > > > --- a/Documentation/MyFirstObjectWalk.txt\n> > > > > > > > > +++ b/Documentation/MyFirstObjectWalk.txt\n> > > > > > > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> > > > > > > > > By running your walk with and without the filter, you should find\n> > > > > > > > > that the total\n> > > > > > > > > object count in each case is identical. You can also time each invocation of\n> > > > > > > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> > > > > > > > > -to yourself the runtime impact of tracking all omitted objects.\n> > > > > > > > > +to yourself the runtime effect of tracking all omitted objects.\n> > > > > > > > >\n> > > > > > > > > === Changing the Order\n> > > > > > > > >\n> > > > > > > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> > > > > > > > > index 3da4ea98e2..00fcc9d7c7 100644\n> > > > > > > > > --- a/Documentation/config/pack.txt\n> > > > > > > > > +++ b/Documentation/config/pack.txt\n> > > > > > > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> > > > > > > > > This cache is used to speed up the writing object phase by not\n> > > > > > > > > having to recompute the final delta result once the best match\n> > > > > > > > > for all objects is found. Repacking large repositories on machines\n> > > > > > > > > - which are tight with memory might be badly impacted by this though,\n> > > > > > > > > + which are tight with memory might be badly affected by this though,\n> > > > > > > > > especially if this cache pushes the system into swapping.\n> > > > > > > > > A value of 0 means no limit. The smallest size of 1 byte may be\n> > > > > > > > > used to virtually disable this cache. Defaults to 256 MiB.\n> > > > > > > > > diff --git a/Documentation/git-fast-import.txt\n> > > > > > > > > b/Documentation/git-fast-import.txt\n> > > > > > > > > index 39cfa05b28..c6d8e4e1d7 100644\n> > > > > > > > > --- a/Documentation/git-fast-import.txt\n> > > > > > > > > +++ b/Documentation/git-fast-import.txt\n> > > > > > > > > @@ -58,7 +58,7 @@ OPTIONS\n> > > > > > > > > allowing fast-import to access the filesystem outside of the\n> > > > > > > > > repository). These options are disabled by default, but can be\n> > > > > > > > > allowed by providing this option on the command line. This\n> > > > > > > > > - currently impacts only the `export-marks`, `import-marks`, and\n> > > > > > > > > + currently affects only the `export-marks`, `import-marks`, and\n> > > > > > > > > `import-marks-if-exists` feature commands.\n> > > > > > > > > +\n> > > > > > > > > Only enable this option if you trust the program generating the\n> > > > > > > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n> > > > > > > > >\n> > > > > > > > > A `filecopy` command takes effect immediately. Once the source\n> > > > > > > > > location has been copied to the destination any future commands\n> > > > > > > > > -applied to the source location will not impact the destination of\n> > > > > > > > > +applied to the source location will not affect the destination of\n> > > > > > > > > the copy.\n> > > > > > > > >\n> > > > > > > > > `filerename`\n> > > > > > > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> > > > > > > > > A `filerename` command takes effect immediately. Once the source\n> > > > > > > > > location has been renamed to the destination any future commands\n> > > > > > > > > applied to the source location will create new files there and not\n> > > > > > > > > -impact the destination of the rename.\n> > > > > > > > > +affect the destination of the rename.\n> > > > > > > > >\n> > > > > > > > > Note that a `filerename` is the same as a `filecopy` followed by a\n> > > > > > > > > `filedelete` of the source location. There is a slight performance\n> > > > > > > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> > > > > > > > > to be required).\n> > > > > > > > > ~~~~~~~~~~\n> > > > > > > > > Causes fast-import to print the entire `progress` line unmodified to\n> > > > > > > > > its standard output channel (file descriptor 1) when the command is\n> > > > > > > > > -processed from the input stream. The command otherwise has no impact\n> > > > > > > > > +processed from the input stream. The command otherwise has no effect\n> > > > > > > > > on the current import, or on any of fast-import's internal state.\n> > > > > > > > >\n> > > > > > > > > ....\n> > > > > > > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> > > > > > > > > ~~~~~~~~~~\n> > > > > > > > > Causes fast-import to print the SHA-1 corresponding to a mark to\n> > > > > > > > > stdout or to the file descriptor previously arranged with the\n> > > > > > > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> > > > > > > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> > > > > > > > > current import; its purpose is to retrieve SHA-1s that later commits\n> > > > > > > > > might want to refer to in their commit messages.\n> > > > > > > > >\n> > > > > > > > > @@ -1050,7 +1050,7 @@ this output safely.\n> > > > > > > > > ~~~~~~~~~~\n> > > > > > > > > Causes fast-import to print a blob to a file descriptor previously\n> > > > > > > > > arranged with the `--cat-blob-fd` argument. The command otherwise\n> > > > > > > > > -has no impact on the current import; its main purpose is to\n> > > > > > > > > +has no effect on the current import; its main purpose is to\n> > > > > > > > > retrieve blobs that may be in fast-import's memory but not\n> > > > > > > > > accessible from the target repository.\n> > > > > > > > >\n> > > > > > > > > @@ -1366,7 +1366,7 @@ code considerably.\n> > > > > > > > >\n> > > > > > > > > The branch LRU builtin to fast-import tends to behave very well, and the\n> > > > > > > > > cost of activating an inactive branch is so low that bouncing around\n> > > > > > > > > -between branches has virtually no impact on import performance.\n> > > > > > > > > +between branches has virtually no effect on import performance.\n> > > > > > > > >\n> > > > > > > > > Handling Renames\n> > > > > > > > > ~~~~~~~~~~~~~~~~\n> > > > > > > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> > > > > > > > > index 9067c2079e..01cf3b3d16 100644\n> > > > > > > > > --- a/Documentation/git-fetch.txt\n> > > > > > > > > +++ b/Documentation/git-fetch.txt\n> > > > > > > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> > > > > > > > > If left to accumulate, these stale references might make performance\n> > > > > > > > > worse on big and busy repos that have a lot of branch churn, and\n> > > > > > > > > e.g. make the output of commands like `git branch -a --contains\n> > > > > > > > > -` needlessly verbose, as well as impacting anything else\n> > > > > > > > > +` needlessly verbose, as well as affecting anything else\n> > > > > > > > > that'll work with the complete set of known references.\n> > > > > > > > >\n> > > > > > > > > These remote-tracking references can be deleted as a one-off with\n> > > > > > > > > diff --git a/Documentation/technical/hash-function-transition.txt\n> > > > > > > > > b/Documentation/technical/hash-function-transition.txt\n> > > > > > > > > index 7c1630bf83..f4296faffc 100644\n> > > > > > > > > --- a/Documentation/technical/hash-function-transition.txt\n> > > > > > > > > +++ b/Documentation/technical/hash-function-transition.txt\n> > > > > > > > > @@ -42,7 +42,7 @@ mitigations.\n> > > > > > > > >\n> > > > > > > > > If SHA-1 and its variants were to be truly broken, Git's hash function\n> > > > > > > > > could not be considered cryptographically secure any more. This would\n> > > > > > > > > -impact the communication of hash values because we could not trust\n> > > > > > > > > +affect the communication of hash values because we could not trust\n> > > > > > > > > that a given hash value represented the known good version of content\n> > > > > > > > > that the speaker intended.\n> > > > > > > > >\n> > > > > > > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > > > > > > > > index fd480b8645..33c60c49d7 100644\n> > > > > > > > > --- a/Documentation/user-manual.txt\n> > > > > > > > > +++ b/Documentation/user-manual.txt\n> > > > > > > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n> > > > > > > > >\n> > > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > > > > -state without impacting any branches by performing another switch.\n> > > > > > > > > +state without affecting any branches by performing another switch.\n> > > > > > > > >\n> > > > > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > > > > do so (now or later) by using -c with the switch command again. Example:\n> > > > > > > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> > > > > > > > > overwritten by the result of\n> > > > > > > > > the merge when this combining is done cleanly, or overwritten by a\n> > > > > > > > > half-merged results when this combining results in conflicts.\n> > > > > > > > > Therefore, if you have uncommitted changes touching the same files as\n> > > > > > > > > -the ones impacted by the merge, Git will refuse to proceed. Most of\n> > > > > > > > > +the ones affected by the merge, Git will refuse to proceed. Most of\n> > > > > > > > > the time, you will want to commit your changes before you can merge,\n> > > > > > > > > and if you don't, then linkgit:git-stash[1] can take these changes\n> > > > > > > > > away while you're doing the merge, and reapply them afterwards.\n> > > > > > > > > diff --git a/advice.c b/advice.c\n> > > > > > > > > index 164742305f..9cbbb824a9 100644\n> > > > > > > > > --- a/advice.c\n> > > > > > > > > +++ b/advice.c\n> > > > > > > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> > > > > > > > > \"\\n\"\n> > > > > > > > > \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> > > > > > > > > \"changes and commit them, and you can discard any commits you make in this\\n\"\n> > > > > > > > > - \"state without impacting any branches by switching back to a branch.\\n\"\n> > > > > > > > > + \"state without affecting any branches by switching back to a branch.\\n\"\n> > > > > > > > > \"\\n\"\n> > > > > > > > > \"If you want to create a new branch to retain commits you create, you may\\n\"\n> > > > > > > > > \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> > > > > > > > > diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> > > > > > > > > index 3afa81cf9a..24f362d2f4 100644\n> > > > > > > > > --- a/builtin/fast-import.c\n> > > > > > > > > +++ b/builtin/fast-import.c\n> > > > > > > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> > > > > > > > > const char *prefix)\n> > > > > > > > > * We don't parse most options until after we've seen the set of\n> > > > > > > > > * \"feature\" lines at the start of the stream (which allows the command\n> > > > > > > > > * line to override stream data). But we must do an early parse of any\n> > > > > > > > > - * command-line options that impact how we interpret the feature lines.\n> > > > > > > > > + * command-line options that affect how we interpret the feature lines.\n> > > > > > > > > */\n> > > > > > > > > for (i = 1; i < argc; i++) {\n> > > > > > > > > const char *arg = argv[i];\n> > > > > > > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> > > > > > > > > index 525c2d8552..749bbca241 100644\n> > > > > > > > > --- a/builtin/pack-objects.c\n> > > > > > > > > +++ b/builtin/pack-objects.c\n> > > > > > > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> > > > > > > > > /*\n> > > > > > > > > * Mark ourselves as active and see if the next step causes\n> > > > > > > > > * us to cycle to another active object. It's important to do\n> > > > > > > > > - * this _before_ we loop, because it impacts where we make the\n> > > > > > > > > + * this _before_ we loop, because it affects where we make the\n> > > > > > > > > * cut, and thus how our total_depth counter works.\n> > > > > > > > > * E.g., We may see a partial loop like:\n> > > > > > > > > *\n> > > > > > > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> > > > > > > > > index f0e80bd7f0..92979ec770 100644\n> > > > > > > > > --- a/contrib/coccinelle/README\n> > > > > > > > > +++ b/contrib/coccinelle/README\n> > > > > > > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> > > > > > > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.\n> > > > > > > > >\n> > > > > > > > > This allows to expose plans of pending large scale refactorings without\n> > > > > > > > > - impacting the bad pattern checks.\n> > > > > > > > > + affecting the bad pattern checks.\n> > > > > > > > > diff --git a/dir.c b/dir.c\n> > > > > > > > > index 3474e67e8f..235e26a90e 100644\n> > > > > > > > > --- a/dir.c\n> > > > > > > > > +++ b/dir.c\n> > > > > > > > > @@ -2144,7 +2144,7 @@ static enum path_treatment\n> > > > > > > > > treat_path_fast(struct dir_struct *dir,\n> > > > > > > > > /*\n> > > > > > > > > * We get path_recurse in the first run when\n> > > > > > > > > * directory_exists_in_index() returns index_nonexistent. We\n> > > > > > > > > - * are sure that new changes in the index does not impact the\n> > > > > > > > > + * are sure that new changes in the index does not affect the\n> > > > > > > > > * outcome. Return now.\n> > > > > > > > > */\n> > > > > > > > > return path_recurse;\n> > > > > > > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> > > > > > > > > index d0e0e019ea..1fcb98443c 100755\n> > > > > > > > > --- a/t/perf/p5550-fetch-tags.sh\n> > > > > > > > > +++ b/t/perf/p5550-fetch-tags.sh\n> > > > > > > > > @@ -8,7 +8,7 @@ follows.\n> > > > > > > > >\n> > > > > > > > > The parent repository has a large number of tags which are disconnected from\n> > > > > > > > > the rest of history. That makes them candidates for tag-following, but we never\n> > > > > > > > > -actually grab them (and thus they will impact each subsequent fetch).\n> > > > > > > > > +actually grab them (and thus they will affect each subsequent fetch).\n> > > > > > > > >\n> > > > > > > > > The child repository is a clone of parent, without the tags, and is at least\n> > > > > > > > > one commit behind the parent (meaning that we will fetch one object and then\n> > > > > > > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> > > > > > > > > index a594b4aa7d..95daba4000 100755\n> > > > > > > > > --- a/t/t0008-ignores.sh\n> > > > > > > > > +++ b/t/t0008-ignores.sh\n> > > > > > > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> > > > > > > > > # test standard ignores\n> > > > > > > > >\n> > > > > > > > > # First make sure that the presence of a file in the working tree\n> > > > > > > > > -# does not impact results, but that the presence of a file in the\n> > > > > > > > > +# does not affect results, but that the presence of a file in the\n> > > > > > > > > # index does unless the --no-index option is used.\n> > > > > > > > >\n> > > > > > > > > for subdir in '' 'a/'\n> > > > > > > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> > > > > > > > > index f028fd1418..a9348f655a 100755\n> > > > > > > > > --- a/t/t0303-credential-external.sh\n> > > > > > > > > +++ b/t/t0303-credential-external.sh\n> > > > > > > > > @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> > > > > > > > > eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n> > > > > > > > >\n> > > > > > > > > # clean before the test in case there is cruft left\n> > > > > > > > > -# over from a previous run that would impact results\n> > > > > > > > > +# over from a previous run that would affect results\n> > > > > > > > > helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > > > > > > >\n> > > > > > > > > helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> > > > > > > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> > > > > > > > > index bc46713a43..568c258c5a 100755\n> > > > > > > > > --- a/t/t2020-checkout-detach.sh\n> > > > > > > > > +++ b/t/t2020-checkout-detach.sh\n> > > > > > > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> > > > > > > > > no SHA-1 ellipsis when not as\n> > > > > > > > >\n> > > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > > > > - state without impacting any branches by switching back to a branch.\n> > > > > > > > > + state without affecting any branches by switching back to a branch.\n> > > > > > > > >\n> > > > > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > > > > do so (now or later) by using -c with the switch command. Example:\n> > > > > > > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> > > > > > > > > print SHA-1 ellipsis when asked\n> > > > > > > > >\n> > > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental\n> > > > > > > > > changes and commit them, and you can discard any commits you make in this\n> > > > > > > > > - state without impacting any branches by switching back to a branch.\n> > > > > > > > > + state without affecting any branches by switching back to a branch.\n> > > > > > > > >\n> > > > > > > > > If you want to create a new branch to retain commits you create, you may\n> > > > > > > > > do so (now or later) by using -c with the switch command. Example:\n> > > > > > > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> > > > > > > > > index 6cca8b84a6..97365a7786 100755\n> > > > > > > > > --- a/t/t4013-diff-various.sh\n> > > > > > > > > +++ b/t/t4013-diff-various.sh\n> > > > > > > > > @@ -109,7 +109,7 @@ test_expect_success setup '\n> > > > > > > > > git checkout -f master &&\n> > > > > > > > >\n> > > > > > > > > # Same merge as master, but with parents reversed. Hide it in a\n> > > > > > > > > - # pseudo-ref to avoid impacting tests with --all.\n> > > > > > > > > + # pseudo-ref to avoid affecting tests with --all.\n> > > > > > > > > commit=$(echo reverse |\n> > > > > > > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> > > > > > > > > git update-ref REVERSE $commit &&\n> > > > > > > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> > > > > > > > > index 7204799a0b..33a6efce2f 100755\n> > > > > > > > > --- a/t/t5000-tar-tree.sh\n> > > > > > > > > +++ b/t/t5000-tar-tree.sh\n> > > > > > > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> > > > > > > > > # Pull the size and date of each entry in a tarfile using the system tar.\n> > > > > > > > > #\n> > > > > > > > > # We'll pull out only the year from the date; that avoids any question of\n> > > > > > > > > -# timezones impacting the result (as long as we keep our test times away from a\n> > > > > > > > > +# timezones affecting the result (as long as we keep our test times away from a\n> > > > > > > > > # year boundary; our reference times are all in August).\n> > > > > > > > > #\n> > > > > > > > > # The output of tar_info is expected to be \" \", both in decimal. It\n> > > > > > > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> > > > > > > > > index 6348e8d733..ff65f86f50 100644\n> > > > > > > > > --- a/t/test-lib-functions.sh\n> > > > > > > > > +++ b/t/test-lib-functions.sh\n> > > > > > > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> > > > > > > > > }\n> > > > > > > > >\n> > > > > > > > > # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> > > > > > > > > -# it also works for shell functions (though those functions cannot impact\n> > > > > > > > > +# it also works for shell functions (though those functions cannot affect\n> > > > > > > > > # the environment outside of the test_env invocation).\n> > > > > > > > > test_env () {\n> > > > > > > > > (\n> > > > > > > > > --\n> > > > > > > > > 2.17.1\n> > > > > > > > >\n> > > > > > > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada wrote:\n> > > > > > > > > >\n> > > > > > > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King wrote:\n> > > > > > > > > > >\n> > > > > > > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n> > > > > > > > > > >\n> > > > > > > > > > > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > > > > > > > > > > problem the word \"impact\" in itself is not \"jargon\".\n> > > > > > > > > > > >\n> > > > > > > > > > > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > > > > > > > > > > strong or market influence\" (n.) when used figuratively; it is not\n> > > > > > > > > > > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > > > > > > > > > > all of the entries you've cited. Using it as such is the incorrect\n> > > > > > > > > > > > part, so those are the instances I've changed in the diff.\n> > > > > > > > > > >\n> > > > > > > > > > > Er, is that true? From Michal's definitions:\n> > > > > > > > > > >\n> > > > > > > > > > > > > From The Collaborative International Dictionary of English v.0.48 :\n> > > > > > > > > > > > [...]\n> > > > > > > > > > > > > 2. To affect or influence, especially in a significant or\n> > > > > > > > > > >\n> > > > > > > > > > > It literally uses \"affect\" to define it. The \"especially significant\"\n> > > > > > > > > > > does not apply to many, but I don't think that makes it necessarily\n> > > > > > > > > > > wrong to use impact to mean \"affect\".\n> > > > > > > > > >\n> > > > > > > > > > I was drawing attention to the \"especially significant\" bit and the\n> > > > > > > > > > like being there in all the entries. I'm not sure about these\n> > > > > > > > > > dictionaries, but the definition is hyperbolic / violent / shocking in\n> > > > > > > > > > every reputable dictionary out there: the Oxford English Dictionary,\n> > > > > > > > > > Merriam-Webster, and Collins.\n> > > > > > > > > >\n> > > > > > > > > > >\n> > > > > > > > > > > Likewise:\n> > > > > > > > > > >\n> > > > > > > > > > > > > From WordNet (r) 3.0 (2006) :\n> > > > > > > > > > > > [...]\n> > > > > > > > > > > > > v 1: press or wedge together; pack together\n> > > > > > > > > > > > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > > > > > > > > > > > affect, impact, bear upon, bear on, touch on,\n> > > > > > > > > > > > > touch]\n> > > > > > > > > > >\n> > > > > > > > > > > That is likewise listing \"impact\" and \"affect\" as synonyms.\n> > > > > > > > > > >\n> > > > > > > > > > > I do agree the word is over-used in some forms of writing, but I don't\n> > > > > > > > > > > find anything at all confusing or wrong about the uses that you changed\n> > > > > > > > > > > in your patch. I am a native speaker of English. I'm open to the\n> > > > > > > > > > > argument that non-native speakers may be more confused by the word. But\n> > > > > > > > > > > this seems like mostly a style preference thing, and I'd generally\n> > > > > > > > > > > prefer to leave the contributions and style of the original writers\n> > > > > > > > > > > intact unless there is a good reason not to.\n> > > > > > > > > >\n> > > > > > > > > > I am a native English speaker as well, and there were multiple places\n> > > > > > > > > > where I had to think twice about what the sentences mean. I agree with\n> > > > > > > > > > your sentiment about leaving stylistic preferences intact, but this is\n> > > > > > > > > > actually a semantic one. And given that there is a perfectly good\n> > > > > > > > > > alternative that doesn't have this confusion / jargon status, I wanted\n> > > > > > > > > > to make the change to improve it, especially where it says that in the\n> > > > > > > > > > output of the git command (`git checkout` when in detached HEAD mode).\n> > > > > > > > > >\n> > > > > > > > > > >\n> > > > > > > > > > > Such changes are doubly unwanted in cases like this:\n> > > > > > > > > > >\n> > > > > > > > > > > > --- a/compat/nedmalloc/malloc.c.h\n> > > > > > > > > > > > +++ b/compat/nedmalloc/malloc.c.h\n> > > > > > > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> > > > > > > > > > > > #endif /* (FOOTERS && !INSECURE) */\n> > > > > > > > > > > >\n> > > > > > > > > > > >\n> > > > > > > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */\n> > > > > > > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */\n> > > > > > > > > > > > #if !INSECURE\n> > > > > > > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3\n> > > > > > > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)\n> > > > > > > > > > >\n> > > > > > > > > > > where the text is imported from another project, and we'd prefer to stay\n> > > > > > > > > > > as close to their version as possible (e.g., to avoid unnecessary\n> > > > > > > > > > > conflicts when pulling in new versions).\n> > > > > > > > > >\n> > > > > > > > > > That's fair; I wasn't aware that this was being pulled directly from\n> > > > > > > > > > another project. I can change this back.\n> > > > > > > > > >\n> > > > > > > > > > >\n> > > > > > > > > > > Also, this one should be \"effect\" anyway, as it is a noun.\n> > > > > > > > > >\n> > > > > > > > > > This seems to have slipped through, as I used a text search tool.\n> > > > > > > > > >\n> > > > > > > > > > >\n> > > > > > > > > > > -Peff\n> \n"},{"id":"424130","messageId":"xmqq35utmmll.fsf@gitster.g","threadId":"55436","inReplyTo":"20210511104326.GJ12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-11T13:22:30Z","receivedAt":"2021-05-11T13:22:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michal Suchánek writes:\n\n> Since you can look up the meaning of the word in a general purpose\n> dictionary it should be an acceptable use even if it's less commonly\n> used in some other English-speaking parts of the world.\n> ...\n> They are not confusing in the way they are used. That is 'does not\n> impact' in the maning 'has no or negligible effect', and especially in\n> the cases where the degree of effect is not considered and only there\n> being an effect or not is discussed there is no room for confusion.\n> ...\n> ...\n> This topic somewhat interests me so I was continuing this discussion\n> in the hope that you either provide a specific very confusing use of the\n> word impact in the documentation that triggered creating this patch or\n> some solid evidence that the general use of word 'impact' as synonym for\n> affect/effect is in some way problematic but niether happened.\n>\n> I think this topic has been discussed sufficiently and there is nothing\n> more to add.\n\nThanks.\n\nAs you said, lack of a specific example of what is universally\nconfusing, or at least confusing to a not-so-insignificant part of\nthe readership, was why this change didn't gain much support. There\nmight be one or two such places where the updated text does read\nbetter, but it is not a very good use of reviewers' time to find\nsuch needles in 700+ line haystack of a patch.\n"},{"id":"424184","messageId":"609ad9473d535_6011e2082@natae.notmuch","threadId":"55436","inReplyTo":"20210406092440.GZ6564@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-11T19:21:43Z","receivedAt":"2021-05-11T19:21:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Mon, Apr 05, 2021 at 04:48:58PM -0500, Varun Varada wrote:\n> > There are a bunch of places in the code/docs which use the word \"impact\"\n> > incorrectly. This is especially true of places where it says \"will not\n> > impact\", which suggests that it might have an effect, albeit not as\n> > strong of a one. This commit replaces all of these with their\n> > appropriate alternative so that the docs not only does not use jargon,\n> > but are also unambiguous.\n> \n> Hello,\n> \n> while using \"will not impact\" in an incorrect or unclear way may be a\n> problem the word \"impact\" in itself is not \"jargon\".\n\nFrom Merriam-Webster:\n\n jargon _noun_\n : obscure and often pretentious language marked by circumlocutions and\n long words\n\n> If you are concerned about correctness and clarity of the documentation please\n> avoid spreading misinformation.\n\nUnder certain definition of \"jaron\" Varun's statement would be\nincorrect, but not under all definitions. If you use the definition\nI stated above, \"impact\" can be considered jargon, because it's a bit\nobscure language.\n\nUltimately it doesn't matter if it's jargon or not, only that we have\nbetter alternatives.\n\n> Thanks\n> \n> Michal\n\nMichal, can you please remove quoted lines you are not replying to?\nThose 762 extra lines make it harder for some of us to read the thread.\nWe don't have email guidelines, but if we did, that certain would be one\nof the points.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"424189","messageId":"20210511195723.GL12700@kitsune.suse.cz","threadId":"55436","inReplyTo":"609ad9473d535_6011e2082@natae.notmuch","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-11T19:57:23Z","receivedAt":"2021-05-11T19:57:28Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Tue, May 11, 2021 at 02:21:43PM -0500, Felipe Contreras wrote:\n> Michal Suchánek wrote:\n> > On Mon, Apr 05, 2021 at 04:48:58PM -0500, Varun Varada wrote:\n> > > There are a bunch of places in the code/docs which use the word \"impact\"\n> > > incorrectly. This is especially true of places where it says \"will not\n> > > impact\", which suggests that it might have an effect, albeit not as\n> > > strong of a one. This commit replaces all of these with their\n> > > appropriate alternative so that the docs not only does not use jargon,\n> > > but are also unambiguous.\n> > \n> > Hello,\n> > \n> > while using \"will not impact\" in an incorrect or unclear way may be a\n> > problem the word \"impact\" in itself is not \"jargon\".\n> \n> From Merriam-Webster:\n> \n> jargon _noun_\n> : obscure and often pretentious language marked by circumlocutions and\n> long words\n> \n> > If you are concerned about correctness and clarity of the documentation please\n> > avoid spreading misinformation.\n> \n> Under certain definition of \"jaron\" Varun's statement would be\n> incorrect, but not under all definitions. If you use the definition\n> I stated above, \"impact\" can be considered jargon, because it's a bit\n> obscure language.\n\nDo you have any frequency data that supports your claim that the word\n'impact' is obscure?\n\nIn my view it's common.\n\n> Ultimately it doesn't matter if it's jargon or not, only that we have\n> better alternatives.\n'better' under what metric?\n\nAs already stated if we replaced words with synonyms solely on the basis\nthat some people find one word more fitting or commonly used we could\nend up in a situation that we change between two wordings back and forth\nbecause people from different parts of the world find different words\nmore fitting and common.\n\nThe bar for change should be that the word as used is very unfitting or\nunintelligible.\n\nThanks\n\nMichal\n"},{"id":"424190","messageId":"609ae224aa509_6064920851@natae.notmuch","threadId":"55436","inReplyTo":"CAD2i4DDr3Ftk6RE8cA74iSsJTpC9nEb=Cqvr79pF51BpcWEnsA@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-11T19:59:32Z","receivedAt":"2021-05-11T19:59:37Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Varun Varada wrote:\n> On Tue, 6 Apr 2021 at 04:24, Michal Suchánek wrote:\n> > while using \"will not impact\" in an incorrect or unclear way may be a\n> > problem the word \"impact\" in itself is not \"jargon\".\n> \n> The word means \"to have a strong or marked effect on\" (v.) and \"a\n> strong or market influence\" (n.) when used figuratively; it is not\n> synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> all of the entries you've cited. Using it as such is the incorrect\n> part, so those are the instances I've changed in the diff.\n\nThere are two ways impact can be used as a verb: transitive and\nintransitive, but git doesn't seem to be using the intransitive form. In\nthe transitive form it usually means to strike \"the car impacted the\ntree\". But it can also mean to have a desired effect \"reducing CO2\nemissions impacted climate change\".\n\nNone of these are used in the documentation, we have things like:\n\n the index does not impact the outcome\n\nWhich is clearly wrong (unless we are talking about possitive outcome of\nthe outcome, which makes no sense).\n\nAs a noun it can mean a siginificant or major effect: \"the impact of\nscience\".\n\nHowever, the documentation is not using it that way:\n\n the runtime impact of tracking all omitted objects\n\nThe noun usage is less wrong than the verb usage, but it's still wrong.\n\nThe verb usage could be corrected by changing \"the index does not\nimpact\", to \"the index does not have an impact on\".\n\nBut why bother? The word \"affect\" is a much superior choice.\n\nI'm in favor of this change.\n\n-- \nFelipe Contreras"},{"id":"424195","messageId":"20210511202502.GM12700@kitsune.suse.cz","threadId":"55436","inReplyTo":"609ae224aa509_6064920851@natae.notmuch","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-11T20:25:02Z","receivedAt":"2021-05-11T20:25:07Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Tue, May 11, 2021 at 02:59:32PM -0500, Felipe Contreras wrote:\n> Varun Varada wrote:\n> > On Tue, 6 Apr 2021 at 04:24, Michal Suchánek wrote:\n> > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > problem the word \"impact\" in itself is not \"jargon\".\n> > \n> > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > strong or market influence\" (n.) when used figuratively; it is not\n> > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > all of the entries you've cited. Using it as such is the incorrect\n> > part, so those are the instances I've changed in the diff.\n> \n> There are two ways impact can be used as a verb: transitive and\n> intransitive, but git doesn't seem to be using the intransitive form. In\n> the transitive form it usually means to strike \"the car impacted the\n> tree\". But it can also mean to have a desired effect \"reducing CO2\n> emissions impacted climate change\".\n\nI don't know where you find the 'desired' effect meaning. Certainly none\nof the dictionaries I consulted at random provides such definition.\n\n> \n> None of these are used in the documentation, we have things like:\n> \n> the index does not impact the outcome\n> \n> Which is clearly wrong (unless we are talking about possitive outcome of\n> the outcome, which makes no sense).\n\nIt is not clearly wrong. To me it makes perfect sense. If you want to\nclaim it's wrong please provide a source for your claim. Otherwise it's\njust matter of different opinions of more fitting formulation.\n\n> \n> As a noun it can mean a siginificant or major effect: \"the impact of\n> science\".\n> \n> However, the documentation is not using it that way:\n> \n> the runtime impact of tracking all omitted objects\n> \n> The noun usage is less wrong than the verb usage, but it's still wrong.\n\nWhy is that wrong?\n\nHow did you infer that the effect is insignificant or minor?\n\nIn fact while some dictionaries list 'impact' as 'have strong effect'\nthe Oxford dicrionary lists is as simply synonymous to 'affect'.\n\n> The verb usage could be corrected by changing \"the index does not\n> impact\", to \"the index does not have an impact on\".\n\nWhy is that change needed at all?\n\n> But why bother? The word \"affect\" is a much superior choice.\n\nWhy bother with a chenge at all?\n\nThanks\n\nMichal\n"},{"id":"424210","messageId":"CAD2i4DALKgw2wG6QGs-oQhAHnS3AG1j1BSq2bxjPojVOtw+WjA@mail.gmail.com","threadId":"55436","inReplyTo":"20210511202502.GM12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-05-11T21:38:34Z","receivedAt":"2021-05-11T21:38:47Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Tue, 11 May 2021 at 15:25, Michal Suchánek wrote:\n>\n> On Tue, May 11, 2021 at 02:59:32PM -0500, Felipe Contreras wrote:\n> > Varun Varada wrote:\n> > > On Tue, 6 Apr 2021 at 04:24, Michal Suchánek wrote:\n> > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > problem the word \"impact\" in itself is not \"jargon\".\n> > >\n> > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > strong or market influence\" (n.) when used figuratively; it is not\n> > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > all of the entries you've cited. Using it as such is the incorrect\n> > > part, so those are the instances I've changed in the diff.\n> >\n> > There are two ways impact can be used as a verb: transitive and\n> > intransitive, but git doesn't seem to be using the intransitive form. In\n> > the transitive form it usually means to strike \"the car impacted the\n> > tree\". But it can also mean to have a desired effect \"reducing CO2\n> > emissions impacted climate change\".\n>\n> I don't know where you find the 'desired' effect meaning. Certainly none\n> of the dictionaries I consulted at random provides such definition.\n>\n> >\n> > None of these are used in the documentation, we have things like:\n> >\n> > the index does not impact the outcome\n> >\n> > Which is clearly wrong (unless we are talking about possitive outcome of\n> > the outcome, which makes no sense).\n>\n> It is not clearly wrong. To me it makes perfect sense. If you want to\n> claim it's wrong please provide a source for your claim. Otherwise it's\n> just matter of different opinions of more fitting formulation.\n\nYou agreed that the word \"impact\" means to \"significantly affect\". The\nidea of whether something is *significantly* affected, as opposed to\nconveying the idea that something is affected at all, only arises in\nsituations where degrees of an influence are possible; that's not the\ncase in any of the examples my change is editing (except for the one I\nconceded where it says \"badly impacted\"). Assuming that a reader would\nknow which of those involve degrees of influence are possible and\nwhich aren't, even if every reader of the documentation/command output\nwas familiar, is entirely unnecessary. That's the point here: there is\nthis point of confusion that is entirely avoidable with a simple\none-word change.\n\nRe: your point about me not pointing out specific examples: the\ncommand output for detached HEAD state reads \"you can discard any\ncommits you make in this state without impacting any branches by\nswitching back to a branch\". I'm incredibly passionate about this\nexample. Here, the user is left to think, \"wait...so this will not\nimpact (significantly affect) any branches, but will it affect them?\nAs in, are there side effects that I should be aware of? Where do I go\nto find out what they are?\" All of this mental energy is completely\nunnecessary. Mind you, this is regarding discarding commits, which is\na destructive action.\n\nYou might feel that this is just one example that might need fixing,\nbut I assure you, I've analysed all the other examples and they all\nhave similar problems. It's entirely unnecessary to have this\nconfusion.\n\n>\n> >\n> > As a noun it can mean a siginificant or major effect: \"the impact of\n> > science\".\n> >\n> > However, the documentation is not using it that way:\n> >\n> > the runtime impact of tracking all omitted objects\n> >\n> > The noun usage is less wrong than the verb usage, but it's still wrong.\n>\n> Why is that wrong?\n>\n> How did you infer that the effect is insignificant or minor?\n\nNo one did, and that's the point. All impacts are effects, but not all\neffects are impacts. You yourself acknowledged that there is a\nprevalent tendency to hyperbolize, and the fact that one doesn't know\nwhich it is in this case (or frankly any of the other cases my commit\ntouches) is problematic. This kind of confusion surely doesn't belong\nin technical documentation. And if it is indeed an \"impact\", where is\nthat conveyed? What's so notable about the effect on the runtime?\nThat's the point.\n\n>\n> In fact while some dictionaries list 'impact' as 'have strong effect'\n> the Oxford dicrionary lists is as simply synonymous to 'affect'.\n>\n> > The verb usage could be corrected by changing \"the index does not\n> > impact\", to \"the index does not have an impact on\".\n>\n> Why is that change needed at all?\n>\n> > But why bother? The word \"affect\" is a much superior choice.\n>\n> Why bother with a chenge at all?\n\nIt seems like you already previously agreed with the premise that the\nword means \"a significant effect\" or \"to significantly affect\". I\nunderstand and appreciate your thoroughness to scrutinize changes to\nthe repo, but I'm frankly surprised that such a small change is\nattracting such fierce debate. This is meant to be a change that is\nprobably one of the easiest ones to decide on: it only consists of\none-word changes that don't change functionality, yet undeniably\nreduce confusion.\n\nRe: your previous point about linguistic authorities: yes, there is no\nauthority on usage, but therein lies my point. This doesn't even need\nto rise to the domain of usage, because it is squarely within the\nrealm of semantics. Words mean something, and we all use dictionaries\nto learn about / confirm those meanings. Insofar as all the major\ndictionaries cite the word as \"a significant effect\" / \"to affect\nsignificantly\", that semantic concept doesn't belong in the cases\nwhere I've made changes. And if it does, then those need to be\nclarified (because that's where the real confusion/ambiguity is).\nI.e., it's not \"why is not every case a significant effect?\", but \"why\nare some cases a significant effect?\"\n\n>\n> Thanks\n>\n> Michal\n"},{"id":"424254","messageId":"609b3c4bf3296_678ff2084c@natae.notmuch","threadId":"55436","inReplyTo":"YGzoX9OeWMKXpqtf@coredump.intra.peff.net","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T02:24:11Z","receivedAt":"2021-05-12T02:24:16Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:\n> \n> > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > problem the word \"impact\" in itself is not \"jargon\".\n> > \n> > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > strong or market influence\" (n.) when used figuratively; it is not\n> > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > all of the entries you've cited. Using it as such is the incorrect\n> > part, so those are the instances I've changed in the diff.\n> \n> Er, is that true? From Michal's definitions:\n> \n> > > From The Collaborative International Dictionary of English v.0.48 :\n> > [...]\n> > > 2. To affect or influence, especially in a significant or\n> \n> It literally uses \"affect\" to define it. The \"especially significant\"\n> does not apply to many, but I don't think that makes it necessarily\n> wrong to use impact to mean \"affect\".\n\nIt's not necessarily wrong, but it's also not quite right.\n\nYou can say \"the financial crisis impacted Jeff Bezos\", because he was\naffected, but was he *especially* affected? Nah. On the other hand \"the\nfinancial crisis affected Jeff Bezos\" is something much less\nproblematic.\n\n> Likewise:\n> \n> > > From WordNet (r) 3.0 (2006) :\n> > [...]\n> > > v 1: press or wedge together; pack together\n> > > 2: have an effect upon; \"Will the new rules affect me?\" [syn:\n> > > affect, impact, bear upon, bear on, touch on,\n> > > touch]\n> \n> That is likewise listing \"impact\" and \"affect\" as synonyms.\n\nA synonym can be a word with nearly the same meaning in some senses. Not\nnecessarily exactly the same meaning in all senses.\n\n> I do agree the word is over-used in some forms of writing, but I don't\n> find anything at all confusing or wrong about the uses that you changed\n> in your patch.\n\nIt doesn't need to be confusing to be changed. Most of the changes in\nthe code are not because the original version is confusing, but because\nthe new version is simply better.\n\nDo you have any instance in which a sentence with \"impact\" is *better*\nthan whith one with affect/effect?\n\n-- \nFelipe Contreras\n"},{"id":"424256","messageId":"609b3ed1c280c_678ff2088a@natae.notmuch","threadId":"55436","inReplyTo":"20210428085838.GN6564@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T02:34:57Z","receivedAt":"2021-05-12T02:46:08Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:\n> > Here's the updated diff:\n> \n> As already said multiple general purpose dictionaries recognize '(have)\n> strong effect' as the meaning of 'impact', in some cases even the most\n> common meaning.\n\nHaving a strong effect is not the same as having an effect.\n\n> In case you have some issue with the word 'jargon' Merriam-Webster gives\n> this definition:\n\n...\n> 2: obscure and often pretentious language marked by circumlocutions and long words\n...\n\n> which the word 'impact' does not fulfill.\n\nThat's a value judgement.\n\nThe word \"impact\" as it's used in the git documentation can certainly be\nconsidered \"obsucre language\".\n\n> Further, you would rarely discuss and document an effect that is\n> negligible so in vast majority of cases '(have) strong effect' (ie\n> 'impact') is synonymous to 'affect' and 'affect', respectively.\n\nNobody is saying the effect is negligible.\n\nAn effect can be noticeable, yet not especial in any way.\n\n-- \nFelipe Contreras"},{"id":"424257","messageId":"609b3fc167d3b_678ff208ce@natae.notmuch","threadId":"55436","inReplyTo":"20210428184956.GS6564@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T02:38:57Z","receivedAt":"2021-05-12T02:47:52Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> At any rate 'strong' is always relative. Unless you have a specific\n> reference of average strenth anything can be considered strong or weak\n> depending on point of view.\n\nYes, but \"impact\" implies the effect is strong, \"affect\" on the other\nhand does not imply the effect is weak, merely that there is some (could\nbe strong, weak, or nominal).\n\nThe safe choice is obvious.\n\n-- \nFelipe Contreras"},{"id":"424258","messageId":"609b41ea9a75a_678ff2085d@natae.notmuch","threadId":"55436","inReplyTo":"20210510173502.GH12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T02:48:10Z","receivedAt":"2021-05-12T02:48:14Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Mon, May 10, 2021 at 12:19:05PM -0500, Varun Varada wrote:\n\n> It refers to redundant changes to the codebase which do not improve it in\n> any way.\n\nThis is not the codebase, and what does or not \"improve in any way\"\nthe status quo is relative to who you ask.\n\n> > As for there being no distinction, there's no gradation within the\n> > semantics of this context; this doesn't change the semantics of the\n> > words themselves. Using \"impact\" when what is meant is just \"effect\"\n> > or \"affect\" is incorrect in all such instances.\n> \n> That's your opinion not shared by the authors of the text.\n\nHow do you know? Have you asked them?\n\nJust because person A wrote text X doesn't necessarily mean they think\ntheir version is superior to any and all future suggestions of\nimprovment.\n\n> The authority you refer to is MIT which is known for technical\n> brilliance but not as authority on linguistics.\n\nThe MIT hosted Noam Chomsky for many decadates. Are you really arguing\nNoam Chomsky is not an authority in linguistics?\n\n-- \nFelipe Contreras"},{"id":"424262","messageId":"609b44a559ade_678ff2088@natae.notmuch","threadId":"55436","inReplyTo":"20210511104326.GJ12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T02:59:49Z","receivedAt":"2021-05-12T02:59:57Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> Also there is no single authority on the English language. The language\n> is spoken in multiple distinct countries, and even within one country\n> there is some variation. It also evolves over time.\n\nAnd this is precisely the reason why you target the least common\ndenominator.\n\nDo you have **any** instance in which the sentence with \"affect\" reads\nworse than with \"impact\"?\n\n> Since you can look up the meaning of the word in a general purpose\n> dictionary it should be an acceptable use even if it's less commonly\n> used in some other English-speaking parts of the world.\n\nIf you are writing classic prose, and most of your audience needs to use\nthe dictionary to understand what you meant, you have failed.\n\n> > > If you do wholesale word replacement in the project for no good reason\n> > > it only makes working with the project history harder.\n> > \n> > I'm not sure I understand the sentiment here. As in, the Git history\n> > will be polluted? Because the \"git blame\" command will only show\n> > changes for the lines where I changed the single words.\n> \n> Yes, it will be polluted. And since we have an opinion of another native\n> English speaker that the use of 'impact' as synonym for affect/effect is\n> fine this is clearly a matter of opinion.\n\nIt's not just native English speakers that read the English\ndocumentation.\n\n> This topic somewhat interests me so I was continuing this discussion\n> in the hope that you either provide a specific very confusing use of the\n> word impact in the documentation that triggered creating this patch or\n> some solid evidence that the general use of word 'impact' as synonym for\n> affect/effect is in some way problematic but niether happened.\n\nThis is not how improvements work.\n\nWe have two options: $a, and $b. You argue that $a doesn't really\nprovide any advantages over $b (although it has been clearly demonstrated\nthat it does). But you are not providing any advantage of $b over $a\neither.\n\nLet's turn the tables around; do **you** have any evidence that \"impact\"\nis superior to \"affect\" in **any** instance?\n\n-- \nFelipe Contreras"},{"id":"424263","messageId":"609b454d33df2_678ff208f9@natae.notmuch","threadId":"55436","inReplyTo":"xmqq35utmmll.fsf@gitster.g","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T03:02:37Z","receivedAt":"2021-05-12T03:02:44Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> As you said, lack of a specific example of what is universally\n> confusing, or at least confusing to a not-so-insignificant part of\n> the readership, was why this change didn't gain much support.\n\nThe original version doesn't necessarily need to be confusing.\n\nIt's sufficient that the new version is better.\n\n> There might be one or two such places where the updated text does read\n> better, but it is not a very good use of reviewers' time to find such\n> needles in 700+ line haystack of a patch.\n\nAs a reviewer I will decide where I to allocate my reviewer's time,\nbecause it's my time.\n\n-- \nFelipe Contreras\n"},{"id":"424264","messageId":"609b47043a719_678ff208e@natae.notmuch","threadId":"55436","inReplyTo":"20210511195723.GL12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T03:09:56Z","receivedAt":"2021-05-12T03:10:01Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Tue, May 11, 2021 at 02:21:43PM -0500, Felipe Contreras wrote:\n> > Michal Suchánek wrote:\n\n> > > If you are concerned about correctness and clarity of the documentation please\n> > > avoid spreading misinformation.\n> > \n> > Under certain definition of \"jaron\" Varun's statement would be\n> > incorrect, but not under all definitions. If you use the definition\n> > I stated above, \"impact\" can be considered jargon, because it's a bit\n> > obscure language.\n> \n> Do you have any frequency data that supports your claim that the word\n> 'impact' is obscure?\n\nThis is not how logic works.\n\nIf I don't have frequency data that supports $x, but you have no\nfrequency data that supports !$x, then we return to the default position;\nwe don't know if $x is true or not.\n\nDo **you** have any frequency data that supports the negative claim that\nthe word \"impact\" is not obscure?\n\n> The bar for change should be that the word as used is very unfitting or\n> unintelligible.\n\nNo. The bar is that **nobody** have any problem with \"affect\", and some\npeople have a problem with \"impact\".\n\nDo you have any problem with \"affect\"?\n\n-- \nFelipe Contreras"},{"id":"424267","messageId":"609b49c85d761_678ff208cd@natae.notmuch","threadId":"55436","inReplyTo":"20210511202502.GM12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T03:21:44Z","receivedAt":"2021-05-12T03:21:51Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Tue, May 11, 2021 at 02:59:32PM -0500, Felipe Contreras wrote:\n> > Varun Varada wrote:\n> > > On Tue, 6 Apr 2021 at 04:24, Michal Suchánek wrote:\n> > > > while using \"will not impact\" in an incorrect or unclear way may be a\n> > > > problem the word \"impact\" in itself is not \"jargon\".\n> > > \n> > > The word means \"to have a strong or marked effect on\" (v.) and \"a\n> > > strong or market influence\" (n.) when used figuratively; it is not\n> > > synonymous with \"affect\" and \"effect\", respectively, as shown even by\n> > > all of the entries you've cited. Using it as such is the incorrect\n> > > part, so those are the instances I've changed in the diff.\n> > \n> > There are two ways impact can be used as a verb: transitive and\n> > intransitive, but git doesn't seem to be using the intransitive form. In\n> > the transitive form it usually means to strike \"the car impacted the\n> > tree\". But it can also mean to have a desired effect \"reducing CO2\n> > emissions impacted climate change\".\n> \n> I don't know where you find the 'desired' effect meaning. Certainly none\n> of the dictionaries I consulted at random provides such definition.\n\nYou yourself consulted Merriam-Webster [1]:\n\n impact _verb_\n : to have a direct effect or impact on : impinge on\n\nDid you not? [2]\n\n> > None of these are used in the documentation, we have things like:\n> > \n> > the index does not impact the outcome\n> > \n> > Which is clearly wrong (unless we are talking about possitive outcome of\n> > the outcome, which makes no sense).\n> \n> It is not clearly wrong. To me it makes perfect sense. If you want to\n> claim it's wrong please provide a source for your claim.\n\nMerriam-Webster [1].\n\n> > As a noun it can mean a siginificant or major effect: \"the impact of\n> > science\".\n> > \n> > However, the documentation is not using it that way:\n> > \n> > the runtime impact of tracking all omitted objects\n> > \n> > The noun usage is less wrong than the verb usage, but it's still wrong.\n> \n> Why is that wrong?\n\nBecause it's not a \"a significant or major effect\" [1].\n\n> How did you infer that the effect is insignificant or minor?\n\nI did not.\n\nIf I claim temperature $x is not hot, that doesn't mean I'm claiming\nit's cold.\n\n> In fact while some dictionaries list 'impact' as 'have strong effect'\n> the Oxford dicrionary lists is as simply synonymous to 'affect'.\n\nSynonymous doesn't mean equal. In fact, the Oxford dictionary defines\n\"impact\" as [3]:\n\n the powerful effect that something has on somebody/something\n\nNote: *powerful*.\n\n> > But why bother? The word \"affect\" is a much superior choice.\n> \n> Why bother with a chenge at all?\n\nBecause it's better.\n\nDo you have any evidence that it's worse?\n\n[1] https://www.merriam-webster.com/dictionary/impact\n[2] https://lore.kernel.org/git/20210406092440.GZ6564@kitsune.suse.cz/\n[3] https://www.oxfordlearnersdictionaries.com/definition/english/impact_1\n\n-- \nFelipe Contreras"},{"id":"424271","messageId":"609b4eea1088a_678ff208ba@natae.notmuch","threadId":"55436","inReplyTo":"CAD2i4DALKgw2wG6QGs-oQhAHnS3AG1j1BSq2bxjPojVOtw+WjA@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T03:43:38Z","receivedAt":"2021-05-12T03:43:45Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Varun Varada wrote:\n\n> Re: your point about me not pointing out specific examples: the\n> command output for detached HEAD state reads \"you can discard any\n> commits you make in this state without impacting any branches by\n> switching back to a branch\". I'm incredibly passionate about this\n> example. Here, the user is left to think, \"wait...so this will not\n> impact (significantly affect) any branches, but will it affect them?\n> As in, are there side effects that I should be aware of? Where do I go\n> to find out what they are?\" All of this mental energy is completely\n> unnecessary. Mind you, this is regarding discarding commits, which is\n> a destructive action.\n\nCompletely agree.\n\nI'm not a native speaker of English, but nowadays I use English more\nthan any other language, and when I read *impact* I read alarm bells.\n\nFirst I'm reminded of \"brace for impact\", which something nobody should\ntake lightly (native speaker or not), and when I search for \"impact\" on\nIMDB the first result I find is Deep Impact [1]. Not something bland.\nMaybe my understanding of the word has been tainted by my experience,\nsure...\n\nBut I'm still waiting for anybody to explain what's wrong with \"affect\".\n\n> > > But why bother? The word \"affect\" is a much superior choice.\n> >\n> > Why bother with a chenge at all?\n> \n> It seems like you already previously agreed with the premise that the\n> word means \"a significant effect\" or \"to significantly affect\". I\n> understand and appreciate your thoroughness to scrutinize changes to\n> the repo, but I'm frankly surprised that such a small change is\n> attracting such fierce debate. This is meant to be a change that is\n> probably one of the easiest ones to decide on: it only consists of\n> one-word changes that don't change functionality, yet undeniably\n> reduce confusion.\n\nWhen I started contributing to the git project more than 10 years ago I\nnoticed precisely the same thing.\n\nIt is a paradox called \"the bikeshedding effect\". When you contribute a\ncomplex and convoluted change it's easier to get it in because few people\ncan object (as few people can understand it). But when you contribute a\nchange as simple as changing the color of something, then *everyone* can\nopine (literally).\n\nThat's why the simplest changes tend to be the most difficult.\n\nAdditionally in my opinion the git project has a language problem, but\nthat's a separate subject.\n\n> Re: your previous point about linguistic authorities: yes, there is no\n> authority on usage, but therein lies my point. This doesn't even need\n> to rise to the domain of usage, because it is squarely within the\n> realm of semantics. Words mean something, and we all use dictionaries\n> to learn about / confirm those meanings. Insofar as all the major\n> dictionaries cite the word as \"a significant effect\" / \"to affect\n> significantly\", that semantic concept doesn't belong in the cases\n> where I've made changes. And if it does, then those need to be\n> clarified (because that's where the real confusion/ambiguity is).\n> I.e., it's not \"why is not every case a significant effect?\", but \"why\n> are some cases a significant effect?\"\n\nI often find it's easier to flip the problem around (from Karl Popper's\nfalsification principle).\n\nIt should not be your duty to prove that all swans are white (which is\nimpossible), it's the duty of the skeptics to prove that a single swan\nis black.\n\nI haven't seen a single person in this thread pointing out what's wrong\nwith \"affect\".\n\nCheers.\n\n[1] https://www.imdb.com/title/tt0120647/\n\n-- \nFelipe Contreras\n"},{"id":"424273","messageId":"20210512040926.GN12700@kitsune.suse.cz","threadId":"55436","inReplyTo":"609b4eea1088a_678ff208ba@natae.notmuch","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-12T04:09:26Z","receivedAt":"2021-05-12T04:09:29Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:\n> Varun Varada wrote:\n> \n> > Re: your point about me not pointing out specific examples: the\n> > command output for detached HEAD state reads \"you can discard any\n> > commits you make in this state without impacting any branches by\n> > switching back to a branch\". I'm incredibly passionate about this\n> > example. Here, the user is left to think, \"wait...so this will not\n> > impact (significantly affect) any branches, but will it affect them?\n> > As in, are there side effects that I should be aware of? Where do I go\n> > to find out what they are?\" All of this mental energy is completely\n> > unnecessary. Mind you, this is regarding discarding commits, which is\n> > a destructive action.\n> \n> Completely agree.\n> \n> I'm not a native speaker of English, but nowadays I use English more\n> than any other language, and when I read *impact* I read alarm bells.\n> \n> First I'm reminded of \"brace for impact\", which something nobody should\n> take lightly (native speaker or not), and when I search for \"impact\" on\n> IMDB the first result I find is Deep Impact [1]. Not something bland.\n> Maybe my understanding of the word has been tainted by my experience,\n> sure...\n> \n> But I'm still waiting for anybody to explain what's wrong with \"affect\".\n> \n> > > > But why bother? The word \"affect\" is a much superior choice.\n> > >\n> > > Why bother with a chenge at all?\n> > \n> > It seems like you already previously agreed with the premise that the\n> > word means \"a significant effect\" or \"to significantly affect\". I\n> > understand and appreciate your thoroughness to scrutinize changes to\n> > the repo, but I'm frankly surprised that such a small change is\n> > attracting such fierce debate. This is meant to be a change that is\n> > probably one of the easiest ones to decide on: it only consists of\n> > one-word changes that don't change functionality, yet undeniably\n> > reduce confusion.\n> \n> When I started contributing to the git project more than 10 years ago I\n> noticed precisely the same thing.\n> \n> It is a paradox called \"the bikeshedding effect\". When you contribute a\n> complex and convoluted change it's easier to get it in because few people\n> can object (as few people can understand it). But when you contribute a\n> change as simple as changing the color of something, then *everyone* can\n> opine (literally).\n\nYou forget that what you are doing right now is bikeshedding after the\nfact.\n\nYou can use 'affect' or 'impact' and it generally conveys the same\nmeaning. Some speakers find 'affect' more natural. Clearly other\nspeakers such as authors of the changes that use the word 'impact' find\n'impact' more natural. If we give in to the desire to pick the more\nnatural sounding synonym we will get endless back and forth of patches\nchanging one synonym to another.\n\nThanks\n\nMichal\n"},{"id":"424274","messageId":"20210512041138.GO12700@kitsune.suse.cz","threadId":"55436","inReplyTo":"609b47043a719_678ff208e@natae.notmuch","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-12T04:11:38Z","receivedAt":"2021-05-12T04:11:41Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Tue, May 11, 2021 at 10:09:56PM -0500, Felipe Contreras wrote:\n> Michal Suchánek wrote:\n> > On Tue, May 11, 2021 at 02:21:43PM -0500, Felipe Contreras wrote:\n> > > Michal Suchánek wrote:\n> \n> > > > If you are concerned about correctness and clarity of the documentation please\n> > > > avoid spreading misinformation.\n> > > \n> > > Under certain definition of \"jaron\" Varun's statement would be\n> > > incorrect, but not under all definitions. If you use the definition\n> > > I stated above, \"impact\" can be considered jargon, because it's a bit\n> > > obscure language.\n> > \n> > Do you have any frequency data that supports your claim that the word\n> > 'impact' is obscure?\n> \n> This is not how logic works.\n> \n> If I don't have frequency data that supports $x, but you have no\n> frequency data that supports !$x, then we return to the default position;\n> we don't know if $x is true or not.\n> \n> Do **you** have any frequency data that supports the negative claim that\n> the word \"impact\" is not obscure?\n\nI don't need that data. You are proposing a change so it is your duty to\nsupport your claim that the change is worthwhile.\nOtherwise it's a change just for the sake of change.\n\n> \n> > The bar for change should be that the word as used is very unfitting or\n> > unintelligible.\n> \n> No. The bar is that **nobody** have any problem with \"affect\", and some\n> people have a problem with \"impact\".\n\nAnd that's established how, specifically?\n\nThanks\n\nMichal\n"},{"id":"424282","messageId":"609b63e48fd49_6d7da2086@natae.notmuch","threadId":"55436","inReplyTo":"20210512040926.GN12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T05:13:08Z","receivedAt":"2021-05-12T05:13:16Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:\n> > It is a paradox called \"the bikeshedding effect\". When you contribute a\n> > complex and convoluted change it's easier to get it in because few people\n> > can object (as few people can understand it). But when you contribute a\n> > change as simple as changing the color of something, then *everyone* can\n> > opine (literally).\n> \n> You forget that what you are doing right now is bikeshedding after the\n> fact.\n\nExcept that's not what I'm doing.\n\n> You can use 'affect' or 'impact' and it generally conveys the same\n> meaning.\n\nThat's clearly *your* opinion, but that's not my opinon.\n\nI'm not arguing between blue and red; I'm arguing between water-based and\nlead-based paint.\n\nThe difference may not matter to you, but it matters to me.\n\nIf it's bikeshedding to you, and it \"gnerally conveys the same meaning\",\nwhy are you arguing against?\n\n-- \nFelipe Contreras"},{"id":"424283","messageId":"609b66203c81_6d7da208f8@natae.notmuch","threadId":"55436","inReplyTo":"20210512041138.GO12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T05:22:40Z","receivedAt":"2021-05-12T05:22:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Tue, May 11, 2021 at 10:09:56PM -0500, Felipe Contreras wrote:\n> > Do **you** have any frequency data that supports the negative claim that\n> > the word \"impact\" is not obscure?\n> \n> I don't need that data.\n\n> You are proposing a change so it is your duty to support your claim\n> that the change is worthwhile.\n\nI am not the one proposing the change, but it has been established that\nat least two people find the change worthwhile, and many dictionaries\nfind \"affect\" less problematic than \"impact\".\n\nYou (and others) don't find the change worthline, fair enough.\n\nBut you also can't find anything wrong with the proposed change.\n\nSo let me try to explain the situation programatically:\n\n 1. ($a > $b) * 0\n 2. ($a = $b) * 3\n 3. ($a < $b) * 2\n\nWhich one should we stay with? $a or $b?\n\n-- \nFelipe Contreras"},{"id":"424291","messageId":"20210512064733.GP12700@kitsune.suse.cz","threadId":"55436","inReplyTo":"609b63e48fd49_6d7da2086@natae.notmuch","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-12T06:47:33Z","receivedAt":"2021-05-12T06:47:38Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:\n> Michal Suchánek wrote:\n> > On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:\n> > > It is a paradox called \"the bikeshedding effect\". When you contribute a\n> > > complex and convoluted change it's easier to get it in because few people\n> > > can object (as few people can understand it). But when you contribute a\n> > > change as simple as changing the color of something, then *everyone* can\n> > > opine (literally).\n> > \n> > You forget that what you are doing right now is bikeshedding after the\n> > fact.\n> \n> Except that's not what I'm doing.\n> \n> > You can use 'affect' or 'impact' and it generally conveys the same\n> > meaning.\n> \n> That's clearly *your* opinion, but that's not my opinon.\n> \n> I'm not arguing between blue and red; I'm arguing between water-based and\n> lead-based paint.\n\nNo, you are not. There is no clear problem with 'impact', either.\n\nSo if somebody comes along later and says that they find 'affect'\nconfusing and impact should be used does that need to be accepted as\nwell, back and forth ad nauseam?\n\n> The difference may not matter to you, but it matters to me.\n> \n> If it's bikeshedding to you, and it \"gnerally conveys the same meaning\",\n> why are you arguing against?\n\nSo if 'for' loops and 'while' loops generally convey the same meaning\nshould we accept patches that replace some 'for' loops with 'while'\nlopps or vice versa?\n\nSurely not. There are different situations in which loops can be used,\nand different people find 'for' and 'while' loops clearer and and easier\nto understand in different situations. If you rewrite the piece of code\nthat includes a loop it might be worthwhile to change the loop type for\nclarity, and at the time when the code is added or modified it is time\nto discuss which one is better, not after.\n\nOn the other hand if you state the goal to not have redundant semicolons\nthen even if code with and without redundant semicolons is the same and\nin most cases it does not make any difference for human understanding\neither patches that just remove redundant semicolons work towards a\nspecific goal. That makes them acceptable even if they are very minor\nbecause there is clear metric they improve which makes the inverse patch\nnot acceptable.\n\nIf you want to make the case for 'impact' in general being obscure or\nhard to understand you will have hard time doing so. There are\ndictionaries that recognize 'impact' as synonymous to 'affect' without\nany difference in degree. In the COCA corpus there is around 200k\ninstances of 'effect', around 100k instances of 'affect', and around\n100k instances of 'impact' which makes effect/affect about 3 times more\nfrequent than 'impact'. That's not even an order of magnitude - clearly\nnot enough to claim it obscure. All of the words are within first 1k so\narguably if you have intermediate knowledge of (US) English you should\nbe familiar with all three.\n\nHowever, there is a different corpus that is much more relevant for the\ngit project:\n\n✔ ~/git [master|…9] \n06:35 $ git grep affect | wc -l\n368\n✔ ~/git [master|…9] \n06:41 $ git grep effect | wc -l\n350\n✔ ~/git [master|…9] \n06:42 $ git grep impact | wc -l\n54\n\nThere are only 54 instances of the word 'impact' in the git repository\nwhich make up only 7.5%. It is feasible to eliminate those 54 instances\ncompletely. In doing so you will make the git project use the same\nwording consistently which makes it arguably more approachable to\nnon-native speakers with limited vocabulary. That states a clear metric\nthat is improved by such patch which also makes the reverse patch not\nacceptable and prevents potential for infinite back-and-forth changing\nfrom one synonym to the other.\n\nBonus points if you add a test that prevents adding new instances of\n'impact' in the future.\n\nThanks\n\nMichal\n"},{"id":"424306","messageId":"609b9ab0b1120_6e4e9208cc@natae.notmuch","threadId":"55436","inReplyTo":"20210512064733.GP12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T09:06:56Z","receivedAt":"2021-05-12T09:07:04Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:\n> > Michal Suchánek wrote:\n\n> > > You can use 'affect' or 'impact' and it generally conveys the same\n> > > meaning.\n> > \n> > That's clearly *your* opinion, but that's not my opinon.\n> > \n> > I'm not arguing between blue and red; I'm arguing between water-based and\n> > lead-based paint.\n> \n> No, you are not. There is no clear problem with 'impact', either.\n\nThere's no clear problem *to you*.\n\n> So if somebody comes along later and says that they find 'affect'\n> confusing and impact should be used does that need to be accepted as\n> well, back and forth ad nauseam?\n\nNo. When that happens we start a new discussion, and see where that\nleads.\n\n> > The difference may not matter to you, but it matters to me.\n> > \n> > If it's bikeshedding to you, and it \"gnerally conveys the same meaning\",\n> > why are you arguing against?\n> \n> So if 'for' loops and 'while' loops generally convey the same meaning\n> should we accept patches that replace some 'for' loops with 'while'\n> lopps or vice versa?\n\nYou are not answering my question, and you are providing an irrelevant\nexample.\n\nI don't see any general difference between 'for' loops and 'while'\nloops. But I do see a difference between 'impact' and 'affect'.\n\nYou are starting from the premise that $a is no different than $b.\nThat's your opinion, and I'm not disregarding it. But other people (e.g.\nVarun and me) do have a different opinion.\n\nAgain, to make it crystal clear; you opine that $a and $b are equal, we\nopine that they are not. We don't disregard your opinion, you do\ndisregard ours.\n\nI don't know how much clearer I can make this.\n\n> In the COCA corpus there is around 200k instances of 'effect', around\n> 100k instances of 'affect', and around 100k instances of 'impact'\n> which makes effect/affect about 3 times more frequent than 'impact'.\n> That's not even an order of magnitude - clearly not enough to claim it\n> obscure.\n\nI don't think you understand the point.\n\nThe word \"impact\" is not obscure by any means.\n\nThe Chicxulub impactor (probably an asteroid) did create an impact on\nEarth that probably killed all the non-avian dinosaurs. In that context\nthe word \"impact\" is 100% valid.\n\nAnd you can find many such valid instances in those 100k COCA corpus\ninstances...\n\nBut not all.\n\n\nThe way the word \"impact\" is used in the git documentation is different\nthan the COCA corpus. Not all the instances of the word \"impact\" in the\ngit documentation refer to an event so drastic that it destroyed\nthousands of species.\n\nThe point is very simple; there's valid ways of using the word \"impact\",\nand there's invalid ways of using it. The git documentation for the most\npart uses the word \"impact\" in an invalid way.\n\nHow many times the COCA corpuses uses \"impact\" in $b manner is\nirrelevant to the number of times the git documentation uses the same\nword in $a manner; the same word can have completely (and sometimes\nopposite meanings).\n\nThe word \"literally\" sometimes means the exact opposite of the word\n\"literally\". So if you find 1 million instances of the word \"instance\"\nused in some way, that doesn't matter, because you might be using it in\na different way.\n\n\nSo... Can you answer my question?\n\nDo you have anything against the word \"affect\" in *any* instance?\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"424310","messageId":"20210512100855.GA8544@kitsune.suse.cz","threadId":"55436","inReplyTo":"609b9ab0b1120_6e4e9208cc@natae.notmuch","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-12T10:08:55Z","receivedAt":"2021-05-12T10:09:16Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:\n> Michal Suchánek wrote:\n> > On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:\n> > > Michal Suchánek wrote:\n> \n> > > > You can use 'affect' or 'impact' and it generally conveys the same\n> > > > meaning.\n> > > \n> > > That's clearly *your* opinion, but that's not my opinon.\n> > > \n> > > I'm not arguing between blue and red; I'm arguing between water-based and\n> > > lead-based paint.\n> > \n> > No, you are not. There is no clear problem with 'impact', either.\n> \n> There's no clear problem *to you*.\n> \n> > So if somebody comes along later and says that they find 'affect'\n> > confusing and impact should be used does that need to be accepted as\n> > well, back and forth ad nauseam?\n> \n> No. When that happens we start a new discussion, and see where that\n> leads.\n> \n> > > The difference may not matter to you, but it matters to me.\n> > > \n> > > If it's bikeshedding to you, and it \"gnerally conveys the same meaning\",\n> > > why are you arguing against?\n> > \n> > So if 'for' loops and 'while' loops generally convey the same meaning\n> > should we accept patches that replace some 'for' loops with 'while'\n> > lopps or vice versa?\n> \n> You are not answering my question, and you are providing an irrelevant\n> example.\n> \n> I don't see any general difference between 'for' loops and 'while'\n> loops. But I do see a difference between 'impact' and 'affect'.\n> \n> You are starting from the premise that $a is no different than $b.\n> That's your opinion, and I'm not disregarding it. But other people (e.g.\n> Varun and me) do have a different opinion.\n> \n> Again, to make it crystal clear; you opine that $a and $b are equal, we\n> opine that they are not. We don't disregard your opinion, you do\n> disregard ours.\n> \n> I don't know how much clearer I can make this.\n> \n> > In the COCA corpus there is around 200k instances of 'effect', around\n> > 100k instances of 'affect', and around 100k instances of 'impact'\n> > which makes effect/affect about 3 times more frequent than 'impact'.\n> > That's not even an order of magnitude - clearly not enough to claim it\n> > obscure.\n> \n> I don't think you understand the point.\n> \n> The word \"impact\" is not obscure by any means.\n> \n> The Chicxulub impactor (probably an asteroid) did create an impact on\n> Earth that probably killed all the non-avian dinosaurs. In that context\n> the word \"impact\" is 100% valid.\n> \n> And you can find many such valid instances in those 100k COCA corpus\n> instances...\n> \n> But not all.\n> \n> \n> The way the word \"impact\" is used in the git documentation is different\n> than the COCA corpus. Not all the instances of the word \"impact\" in the\n> git documentation refer to an event so drastic that it destroyed\n> thousands of species.\n> \n> The point is very simple; there's valid ways of using the word \"impact\",\n> and there's invalid ways of using it. The git documentation for the most\n> part uses the word \"impact\" in an invalid way.\n> \n> How many times the COCA corpuses uses \"impact\" in $b manner is\n> irrelevant to the number of times the git documentation uses the same\n> word in $a manner; the same word can have completely (and sometimes\n> opposite meanings).\n> \n> The word \"literally\" sometimes means the exact opposite of the word\n> \"literally\". So if you find 1 million instances of the word \"instance\"\n> used in some way, that doesn't matter, because you might be using it in\n> a different way.\n> \n> \n> So... Can you answer my question?\n> \n> Do you have anything against the word \"affect\" in *any* instance?\n\nYss, the Merriam-Webster dictionary also lists the meaning\n\"to cause illness, symptoms, etc.\" I don't think something that drastic\nshould be included in the git documentation.\n\nSCNR\n"},{"id":"424311","messageId":"20210512103332.GB8544@kitsune.suse.cz","threadId":"55436","inReplyTo":"20210512100855.GA8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-12T10:33:32Z","receivedAt":"2021-05-12T10:33:36Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, May 12, 2021 at 12:08:55PM +0200, Michal Suchánek wrote:\n> On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:\n> > Michal Suchánek wrote:\n> > > On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:\n> > > > Michal Suchánek wrote:\n> > \n> > > > > You can use 'affect' or 'impact' and it generally conveys the same\n> > > > > meaning.\n> > > > \n> > > > That's clearly *your* opinion, but that's not my opinon.\n> > > > \n> > > > I'm not arguing between blue and red; I'm arguing between water-based and\n> > > > lead-based paint.\n> > > \n> > > No, you are not. There is no clear problem with 'impact', either.\n> > \n> > There's no clear problem *to you*.\n> > \n> > > So if somebody comes along later and says that they find 'affect'\n> > > confusing and impact should be used does that need to be accepted as\n> > > well, back and forth ad nauseam?\n> > \n> > No. When that happens we start a new discussion, and see where that\n> > leads.\n> > \n> > > > The difference may not matter to you, but it matters to me.\n> > > > \n> > > > If it's bikeshedding to you, and it \"gnerally conveys the same meaning\",\n> > > > why are you arguing against?\n> > > \n> > > So if 'for' loops and 'while' loops generally convey the same meaning\n> > > should we accept patches that replace some 'for' loops with 'while'\n> > > lopps or vice versa?\n> > \n> > You are not answering my question, and you are providing an irrelevant\n> > example.\n> > \n> > I don't see any general difference between 'for' loops and 'while'\n> > loops. But I do see a difference between 'impact' and 'affect'.\n> > \n> > You are starting from the premise that $a is no different than $b.\n> > That's your opinion, and I'm not disregarding it. But other people (e.g.\n> > Varun and me) do have a different opinion.\n> > \n> > Again, to make it crystal clear; you opine that $a and $b are equal, we\n> > opine that they are not. We don't disregard your opinion, you do\n> > disregard ours.\n> > \n> > I don't know how much clearer I can make this.\n\nAnd changes to git should be based on fact, not opinion.\n\nI don't know how much clearer I can state it.\n\nThanks\n\nMichal\n"},{"id":"424313","messageId":"609bb67c96463_70eac2089d@natae.notmuch","threadId":"55436","inReplyTo":"20210512100855.GA8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T11:05:32Z","receivedAt":"2021-05-12T11:05:41Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:\n> > So... Can you answer my question?\n> > \n> > Do you have anything against the word \"affect\" in *any* instance?\n> \n> Yss, the Merriam-Webster dictionary also lists the meaning\n> \"to cause illness, symptoms, etc.\"\n\nI did not ask you if you could list one definition contrary to the\nintended purpose of the word \"affect\".\n\nI asked you if you have something againt the word \"affect\".\n\nWe can use your same logic to find one definition for the word \"impact\"\ncontrary to your intended purpose.\n\nThat's not the intention of the question.\n\n-- \nFelipe Contreras"},{"id":"424315","messageId":"20210512112059.GD8544@kitsune.suse.cz","threadId":"55436","inReplyTo":"609bb67c96463_70eac2089d@natae.notmuch","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-12T11:20:59Z","receivedAt":"2021-05-12T11:21:03Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, May 12, 2021 at 06:05:32AM -0500, Felipe Contreras wrote:\n> Michal Suchánek wrote:\n> > On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:\n> > > So... Can you answer my question?\n> > > \n> > > Do you have anything against the word \"affect\" in *any* instance?\n> > \n> > Yss, the Merriam-Webster dictionary also lists the meaning\n> > \"to cause illness, symptoms, etc.\"\n> \n> I did not ask you if you could list one definition contrary to the\n> intended purpose of the word \"affect\".\n> \n> I asked you if you have something againt the word \"affect\".\n> \n> We can use your same logic to find one definition for the word \"impact\"\n> contrary to your intended purpose.\n\nThat's exactly the point you have been making, though.\n\n> \n> That's not the intention of the question.\n> \n> -- \n> Felipe Contreras\n"},{"id":"424323","messageId":"8e353a57-8abd-74d0-8b42-488b166e58a2@crashcourse.ca","threadId":"55436","inReplyTo":"20210512112059.GD8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2021-05-12T11:45:05Z","receivedAt":"2021-05-12T12:31:10Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Wed, 12 May 2021, Michal Suchánek wrote:\n\n> On Wed, May 12, 2021 at 06:05:32AM -0500, Felipe Contreras wrote:\n> > Michal Suchánek wrote:\n> > > On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:\n> > > > So... Can you answer my question?\n> > > >\n> > > > Do you have anything against the word \"affect\" in *any* instance?\n> > >\n> > > Yss, the Merriam-Webster dictionary also lists the meaning\n> > > \"to cause illness, symptoms, etc.\"\n> >\n> > I did not ask you if you could list one definition contrary to the\n> > intended purpose of the word \"affect\".\n> >\n> > I asked you if you have something againt the word \"affect\".\n> >\n> > We can use your same logic to find one definition for the word \"impact\"\n> > contrary to your intended purpose.\n>\n> That's exactly the point you have been making, though.\n\n y'all realize that linus torvalds wrote an entire version control\nsystem in less time than it's taken you to argue about what two words\nmean, right?\n\nrday"},{"id":"424343","messageId":"AS8PR02MB7302003EB585EBAA0AB4C6E39C529@AS8PR02MB7302.eurprd02.prod.outlook.com","threadId":"55436","inReplyTo":"8e353a57-8abd-74d0-8b42-488b166e58a2@crashcourse.ca","subject":"RE: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Kerry, Richard","fromEmail":"richard.kerry@atos.net","sentAt":"2021-05-12T15:19:15Z","receivedAt":"2021-05-12T15:21:23Z","isPatch":true,"sender":{"key":"richard.kerry@atos.net","avatar":null},"body":"\nSpeaking as a native (British) English speaker I don't have the slightest problem with the word \"impact\" being used in this context.\n\nRemember English is not one of those languages with an Academy or committee that defines what is correct.\n\nIt might be a different matter for non-native, or non-British speakers. I suppose the question is whether this a matter of preference or comprehensibility. It seems to me to be the former.\n\n\n\nRegards,\nRichard.\n\nPs. Sorry about top-posting. Not sure if I can get Outlook to do a nice set-up for anything else.\n\n\n-----Original Message-----\nFrom: Robert P. J. Day \nSent: 12 May 2021 12:45\nTo: Michal Suchánek \nCc: Felipe Contreras ; Varun Varada ; git@vger.kernel.org\nSubject: Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"\n\nCaution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.\n\nOn Wed, 12 May 2021, Michal Suchánek wrote:\n\n> On Wed, May 12, 2021 at 06:05:32AM -0500, Felipe Contreras wrote:\n> > Michal Suchánek wrote:\n> > > On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:\n> > > > So... Can you answer my question?\n> > > >\n> > > > Do you have anything against the word \"affect\" in *any* instance?\n> > >\n> > > Yss, the Merriam-Webster dictionary also lists the meaning \"to \n> > > cause illness, symptoms, etc.\"\n> >\n> > I did not ask you if you could list one definition contrary to the \n> > intended purpose of the word \"affect\".\n> >\n> > I asked you if you have something againt the word \"affect\".\n> >\n> > We can use your same logic to find one definition for the word \"impact\"\n> > contrary to your intended purpose.\n>\n> That's exactly the point you have been making, though.\n\n y'all realize that linus torvalds wrote an entire version control system in less time than it's taken you to argue about what two words mean, right?\n\nrday\n"},{"id":"424349","messageId":"CAD2i4DA80wWHLkH135=+pJ05+xAvH6UG9Pg-G2gv0mm=DDEskw@mail.gmail.com","threadId":"55436","inReplyTo":"20210512041138.GO12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-05-12T16:39:58Z","receivedAt":"2021-05-12T17:55:34Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Tue, 11 May 2021 at 23:11, Michal Suchánek wrote:\n>\n> On Tue, May 11, 2021 at 10:09:56PM -0500, Felipe Contreras wrote:\n> > Michal Suchánek wrote:\n> > > On Tue, May 11, 2021 at 02:21:43PM -0500, Felipe Contreras wrote:\n> > > > Michal Suchánek wrote:\n> >\n> > > > > If you are concerned about correctness and clarity of the documentation please\n> > > > > avoid spreading misinformation.\n> > > >\n> > > > Under certain definition of \"jaron\" Varun's statement would be\n> > > > incorrect, but not under all definitions. If you use the definition\n> > > > I stated above, \"impact\" can be considered jargon, because it's a bit\n> > > > obscure language.\n> > >\n> > > Do you have any frequency data that supports your claim that the word\n> > > 'impact' is obscure?\n> >\n> > This is not how logic works.\n> >\n> > If I don't have frequency data that supports $x, but you have no\n> > frequency data that supports !$x, then we return to the default position;\n> > we don't know if $x is true or not.\n> >\n> > Do **you** have any frequency data that supports the negative claim that\n> > the word \"impact\" is not obscure?\n>\n> I don't need that data. You are proposing a change so it is your duty to\n> support your claim that the change is worthwhile.\n> Otherwise it's a change just for the sake of change.\n>\n> >\n> > > The bar for change should be that the word as used is very unfitting or\n> > > unintelligible.\n> >\n> > No. The bar is that **nobody** have any problem with \"affect\", and some\n> > people have a problem with \"impact\".\n>\n> And that's established how, specifically?\n\nBy way of dictionaries and style guides which universally agree on the\nmeaning of \"affect\"/\"effect\", but do not on that of (and even\nexplicitly discourage) \"impact\".\n\n>\n> Thanks\n>\n> Michal\n"},{"id":"424350","messageId":"CAD2i4DBF3Tvf62Zyh0XnNH=5ifTD2QQNL5Fx01UHMzoTn3OMVw@mail.gmail.com","threadId":"55436","inReplyTo":"20210512064733.GP12700@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-05-12T16:47:15Z","receivedAt":"2021-05-12T17:55:35Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Wed, 12 May 2021 at 01:47, Michal Suchánek wrote:\n>\n> On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:\n> > Michal Suchánek wrote:\n> > > On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:\n> > > > It is a paradox called \"the bikeshedding effect\". When you contribute a\n> > > > complex and convoluted change it's easier to get it in because few people\n> > > > can object (as few people can understand it). But when you contribute a\n> > > > change as simple as changing the color of something, then *everyone* can\n> > > > opine (literally).\n> > >\n> > > You forget that what you are doing right now is bikeshedding after the\n> > > fact.\n> >\n> > Except that's not what I'm doing.\n> >\n> > > You can use 'affect' or 'impact' and it generally conveys the same\n> > > meaning.\n> >\n> > That's clearly *your* opinion, but that's not my opinon.\n> >\n> > I'm not arguing between blue and red; I'm arguing between water-based and\n> > lead-based paint.\n>\n> No, you are not. There is no clear problem with 'impact', either.\n>\n> So if somebody comes along later and says that they find 'affect'\n> confusing and impact should be used does that need to be accepted as\n> well, back and forth ad nauseam?\n\nThis is whataboutism and hypothetical. But even if one were to\ndisregard those facts, I'm willing to bet actual money that no one (at\nleast anyone with access to a dictionary or even a basic grasp of the\nEnglish language) would do this because \"affect\" has a universal\ndefinition and is not in the realm of jargon in any dictionary or\nstyle guide. The same cannot be said about \"impact\".\n\n>\n> > The difference may not matter to you, but it matters to me.\n> >\n> > If it's bikeshedding to you, and it \"gnerally conveys the same meaning\",\n> > why are you arguing against?\n>\n> So if 'for' loops and 'while' loops generally convey the same meaning\n> should we accept patches that replace some 'for' loops with 'while'\n> lopps or vice versa?\n>\n> Surely not. There are different situations in which loops can be used,\n> and different people find 'for' and 'while' loops clearer and and easier\n> to understand in different situations. If you rewrite the piece of code\n> that includes a loop it might be worthwhile to change the loop type for\n> clarity, and at the time when the code is added or modified it is time\n> to discuss which one is better, not after.\n>\n> On the other hand if you state the goal to not have redundant semicolons\n> then even if code with and without redundant semicolons is the same and\n> in most cases it does not make any difference for human understanding\n> either patches that just remove redundant semicolons work towards a\n> specific goal. That makes them acceptable even if they are very minor\n> because there is clear metric they improve which makes the inverse patch\n> not acceptable.\n>\n> If you want to make the case for 'impact' in general being obscure or\n> hard to understand you will have hard time doing so. There are\n> dictionaries that recognize 'impact' as synonymous to 'affect' without\n> any difference in degree. In the COCA corpus there is around 200k\n> instances of 'effect', around 100k instances of 'affect', and around\n> 100k instances of 'impact' which makes effect/affect about 3 times more\n> frequent than 'impact'. That's not even an order of magnitude - clearly\n> not enough to claim it obscure. All of the words are within first 1k so\n> arguably if you have intermediate knowledge of (US) English you should\n> be familiar with all three.\n>\n> However, there is a different corpus that is much more relevant for the\n> git project:\n>\n> ✔ ~/git [master|…9]\n> 06:35 $ git grep affect | wc -l\n> 368\n> ✔ ~/git [master|…9]\n> 06:41 $ git grep effect | wc -l\n> 350\n> ✔ ~/git [master|…9]\n> 06:42 $ git grep impact | wc -l\n> 54\n>\n> There are only 54 instances of the word 'impact' in the git repository\n> which make up only 7.5%. It is feasible to eliminate those 54 instances\n> completely. In doing so you will make the git project use the same\n> wording consistently which makes it arguably more approachable to\n> non-native speakers with limited vocabulary. That states a clear metric\n> that is improved by such patch which also makes the reverse patch not\n> acceptable and prevents potential for infinite back-and-forth changing\n> from one synonym to the other.\n>\n> Bonus points if you add a test that prevents adding new instances of\n> 'impact' in the future.\n\nSo you're saying you're OK with getting rid of all instances of\n\"impact\"? I'm for this, but insofar as I searched the code base, I\nonly found the ones I'm changing in my patch (save for a couple that,\nas a previous reviewer mentioned, are included from other repos, so I\nleft those).\n\n>\n> Thanks\n>\n> Michal\n"},{"id":"424351","messageId":"20210512170153.GE8544@kitsune.suse.cz","threadId":"55436","inReplyTo":"CAD2i4DBF3Tvf62Zyh0XnNH=5ifTD2QQNL5Fx01UHMzoTn3OMVw@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-12T17:01:53Z","receivedAt":"2021-05-12T17:55:35Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, May 12, 2021 at 11:47:15AM -0500, Varun Varada wrote:\n> On Wed, 12 May 2021 at 01:47, Michal Suchánek wrote:\n> >\n> > On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:\n> > > Michal Suchánek wrote:\n> > > > On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:\n> > > > > It is a paradox called \"the bikeshedding effect\". When you contribute a\n> > > > > complex and convoluted change it's easier to get it in because few people\n> > > > > can object (as few people can understand it). But when you contribute a\n> > > > > change as simple as changing the color of something, then *everyone* can\n> > > > > opine (literally).\n> > > >\n> > > > You forget that what you are doing right now is bikeshedding after the\n> > > > fact.\n> > >\n> > > Except that's not what I'm doing.\n> > >\n> > > > You can use 'affect' or 'impact' and it generally conveys the same\n> > > > meaning.\n> > >\n> > > That's clearly *your* opinion, but that's not my opinon.\n> > >\n> > > I'm not arguing between blue and red; I'm arguing between water-based and\n> > > lead-based paint.\n> >\n> > No, you are not. There is no clear problem with 'impact', either.\n> >\n> > So if somebody comes along later and says that they find 'affect'\n> > confusing and impact should be used does that need to be accepted as\n> > well, back and forth ad nauseam?\n> \n> This is whataboutism and hypothetical. But even if one were to\n> disregard those facts, I'm willing to bet actual money that no one (at\n> least anyone with access to a dictionary or even a basic grasp of the\n> English language) would do this because \"affect\" has a universal\n> definition and is not in the realm of jargon in any dictionary or\n> style guide. The same cannot be said about \"impact\".\n> \n> >\n> > > The difference may not matter to you, but it matters to me.\n> > >\n> > > If it's bikeshedding to you, and it \"gnerally conveys the same meaning\",\n> > > why are you arguing against?\n> >\n> > So if 'for' loops and 'while' loops generally convey the same meaning\n> > should we accept patches that replace some 'for' loops with 'while'\n> > lopps or vice versa?\n> >\n> > Surely not. There are different situations in which loops can be used,\n> > and different people find 'for' and 'while' loops clearer and and easier\n> > to understand in different situations. If you rewrite the piece of code\n> > that includes a loop it might be worthwhile to change the loop type for\n> > clarity, and at the time when the code is added or modified it is time\n> > to discuss which one is better, not after.\n> >\n> > On the other hand if you state the goal to not have redundant semicolons\n> > then even if code with and without redundant semicolons is the same and\n> > in most cases it does not make any difference for human understanding\n> > either patches that just remove redundant semicolons work towards a\n> > specific goal. That makes them acceptable even if they are very minor\n> > because there is clear metric they improve which makes the inverse patch\n> > not acceptable.\n> >\n> > If you want to make the case for 'impact' in general being obscure or\n> > hard to understand you will have hard time doing so. There are\n> > dictionaries that recognize 'impact' as synonymous to 'affect' without\n> > any difference in degree. In the COCA corpus there is around 200k\n> > instances of 'effect', around 100k instances of 'affect', and around\n> > 100k instances of 'impact' which makes effect/affect about 3 times more\n> > frequent than 'impact'. That's not even an order of magnitude - clearly\n> > not enough to claim it obscure. All of the words are within first 1k so\n> > arguably if you have intermediate knowledge of (US) English you should\n> > be familiar with all three.\n> >\n> > However, there is a different corpus that is much more relevant for the\n> > git project:\n> >\n> > ✔ ~/git [master|…9]\n> > 06:35 $ git grep affect | wc -l\n> > 368\n> > ✔ ~/git [master|…9]\n> > 06:41 $ git grep effect | wc -l\n> > 350\n> > ✔ ~/git [master|…9]\n> > 06:42 $ git grep impact | wc -l\n> > 54\n> >\n> > There are only 54 instances of the word 'impact' in the git repository\n> > which make up only 7.5%. It is feasible to eliminate those 54 instances\n> > completely. In doing so you will make the git project use the same\n> > wording consistently which makes it arguably more approachable to\n> > non-native speakers with limited vocabulary. That states a clear metric\n> > that is improved by such patch which also makes the reverse patch not\n> > acceptable and prevents potential for infinite back-and-forth changing\n> > from one synonym to the other.\n> >\n> > Bonus points if you add a test that prevents adding new instances of\n> > 'impact' in the future.\n> \n> So you're saying you're OK with getting rid of all instances of\n> \"impact\"? I'm for this, but insofar as I searched the code base, I\n> only found the ones I'm changing in my patch (save for a couple that,\n> as a previous reviewer mentioned, are included from other repos, so I\n> left those).\n\nYes, I am not opposed to the change in principle. You just failed to\nprovide any valid reason.\n\nPart of writing a patch is coming up with sound reasoning why the change\nis desirable and stating that clearly in the commit message.\n\nI don't know if this reasoning is acceptable to git maintainers but at\nleast there is some real data it is based on.\n\nThanks\n\nMichal\n"},{"id":"424362","messageId":"609c112066acd_71bd1208aa@natae.notmuch","threadId":"55436","inReplyTo":"20210512170153.GE8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T17:32:16Z","receivedAt":"2021-05-12T17:55:38Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Wed, May 12, 2021 at 11:47:15AM -0500, Varun Varada wrote:\n> > So you're saying you're OK with getting rid of all instances of\n> > \"impact\"? I'm for this, but insofar as I searched the code base, I\n> > only found the ones I'm changing in my patch (save for a couple that,\n> > as a previous reviewer mentioned, are included from other repos, so I\n> > left those).\n> \n> Yes, I am not opposed to the change in principle.\n\nGood, so you accept you see nothing wrong with \"affect\".\n\n> You just failed to provide any valid reason.\n\n*In your opinion*.\n\nIn my opinion the problems with the word \"impact\" have been clearly\nexplained.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"424364","messageId":"20210512180418.GF8544@kitsune.suse.cz","threadId":"55436","inReplyTo":"609c112066acd_71bd1208aa@natae.notmuch","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-12T18:04:18Z","receivedAt":"2021-05-12T20:34:59Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, May 12, 2021 at 12:32:16PM -0500, Felipe Contreras wrote:\n> Michal Suchánek wrote:\n> > On Wed, May 12, 2021 at 11:47:15AM -0500, Varun Varada wrote:\n> > > So you're saying you're OK with getting rid of all instances of\n> > > \"impact\"? I'm for this, but insofar as I searched the code base, I\n> > > only found the ones I'm changing in my patch (save for a couple that,\n> > > as a previous reviewer mentioned, are included from other repos, so I\n> > > left those).\n> > \n> > Yes, I am not opposed to the change in principle.\n> \n> Good, so you accept you see nothing wrong with \"affect\".\n> \n> > You just failed to provide any valid reason.\n> \n> *In your opinion*.\n> \n> In my opinion the problems with the word \"impact\" have been clearly\n> explained.\n\nHowever, you only brought your personal opinion for the case that\n'impact' is somehow wrong and should be changed. 'impact' and 'affect'\nare equally good based on the past discussion so you will not bring\nchange based on the 'badness' of 'impact'.\n\nYou claim that people who do not want to change 'impact' ignore your\nopinion.\n\nDon't you equally ignore the opinion of people who think 'impact' is\nfine by insisting that the wording be changed based solely on your\nopinion?\n\nCheers\n\nMichal\n"},{"id":"424370","messageId":"609c2f98932f3_71bd120840@natae.notmuch","threadId":"55436","inReplyTo":"20210512180418.GF8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T19:42:16Z","receivedAt":"2021-05-12T20:37:07Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Wed, May 12, 2021 at 12:32:16PM -0500, Felipe Contreras wrote:\n> > Michal Suchánek wrote:\n> > > Yes, I am not opposed to the change in principle.\n> > \n> > Good, so you accept you see nothing wrong with \"affect\".\n> > \n> > > You just failed to provide any valid reason.\n> > \n> > *In your opinion*.\n> > \n> > In my opinion the problems with the word \"impact\" have been clearly\n> > explained.\n> \n> However, you only brought your personal opinion for the case that\n> 'impact' is somehow wrong and should be changed.\n\nNo I didn't. I used dictionary definitions to explain why it's wrong to\nuse it the way git uses both as a noun and a transitive verb.\n\n> 'impact' and 'affect' are equally good based on the past discussion so\n> you will not bring change based on the 'badness' of 'impact'.\n\nThat is your opinion, and its not shared by everyone.\n\nIt's extremely disingenious to elevate your opinion as fact, especially\nwhen this is precisely the thing we are discussing.\n\n> You claim that people who do not want to change 'impact' ignore your\n> opinion.\n\nNo I don't.\n\nI clam *you* pretend other opinions don't even exist.\n\n> Don't you equally ignore the opinion of people who think 'impact' is\n> fine by insisting that the wording be changed based solely on your\n> opinion?\n\nNo, unlike you I acknowledge there's other people with different\nopinions.\n\nHowever, that opinion is that \"impact\" is fine, *not* that \"affect\" is\nbad.\n\n\nIf you and your wife are deciding what to eat for dinner, and you have\ntwo opinions:\n\n 1. Whatever is fine\n 2. I really would like pizza\n\nWhat do you think you should order?\n\n-- \nFelipe Contreras"},{"id":"424393","messageId":"CAD2i4DB0Zt1snCS_iHZrRJ-woeY5eS-WpWpfdvWo2f5Mk5AY1w@mail.gmail.com","threadId":"55436","inReplyTo":"20210512170153.GE8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-05-12T22:52:37Z","receivedAt":"2021-05-12T23:28:01Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Wed, 12 May 2021 at 12:01, Michal Suchánek wrote:\n>\n> On Wed, May 12, 2021 at 11:47:15AM -0500, Varun Varada wrote:\n> > On Wed, 12 May 2021 at 01:47, Michal Suchánek wrote:\n> > >\n> > > On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:\n> > > > Michal Suchánek wrote:\n> > > > > On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:\n> > > > > > It is a paradox called \"the bikeshedding effect\". When you contribute a\n> > > > > > complex and convoluted change it's easier to get it in because few people\n> > > > > > can object (as few people can understand it). But when you contribute a\n> > > > > > change as simple as changing the color of something, then *everyone* can\n> > > > > > opine (literally).\n> > > > >\n> > > > > You forget that what you are doing right now is bikeshedding after the\n> > > > > fact.\n> > > >\n> > > > Except that's not what I'm doing.\n> > > >\n> > > > > You can use 'affect' or 'impact' and it generally conveys the same\n> > > > > meaning.\n> > > >\n> > > > That's clearly *your* opinion, but that's not my opinon.\n> > > >\n> > > > I'm not arguing between blue and red; I'm arguing between water-based and\n> > > > lead-based paint.\n> > >\n> > > No, you are not. There is no clear problem with 'impact', either.\n> > >\n> > > So if somebody comes along later and says that they find 'affect'\n> > > confusing and impact should be used does that need to be accepted as\n> > > well, back and forth ad nauseam?\n> >\n> > This is whataboutism and hypothetical. But even if one were to\n> > disregard those facts, I'm willing to bet actual money that no one (at\n> > least anyone with access to a dictionary or even a basic grasp of the\n> > English language) would do this because \"affect\" has a universal\n> > definition and is not in the realm of jargon in any dictionary or\n> > style guide. The same cannot be said about \"impact\".\n> >\n> > >\n> > > > The difference may not matter to you, but it matters to me.\n> > > >\n> > > > If it's bikeshedding to you, and it \"gnerally conveys the same meaning\",\n> > > > why are you arguing against?\n> > >\n> > > So if 'for' loops and 'while' loops generally convey the same meaning\n> > > should we accept patches that replace some 'for' loops with 'while'\n> > > lopps or vice versa?\n> > >\n> > > Surely not. There are different situations in which loops can be used,\n> > > and different people find 'for' and 'while' loops clearer and and easier\n> > > to understand in different situations. If you rewrite the piece of code\n> > > that includes a loop it might be worthwhile to change the loop type for\n> > > clarity, and at the time when the code is added or modified it is time\n> > > to discuss which one is better, not after.\n> > >\n> > > On the other hand if you state the goal to not have redundant semicolons\n> > > then even if code with and without redundant semicolons is the same and\n> > > in most cases it does not make any difference for human understanding\n> > > either patches that just remove redundant semicolons work towards a\n> > > specific goal. That makes them acceptable even if they are very minor\n> > > because there is clear metric they improve which makes the inverse patch\n> > > not acceptable.\n> > >\n> > > If you want to make the case for 'impact' in general being obscure or\n> > > hard to understand you will have hard time doing so. There are\n> > > dictionaries that recognize 'impact' as synonymous to 'affect' without\n> > > any difference in degree. In the COCA corpus there is around 200k\n> > > instances of 'effect', around 100k instances of 'affect', and around\n> > > 100k instances of 'impact' which makes effect/affect about 3 times more\n> > > frequent than 'impact'. That's not even an order of magnitude - clearly\n> > > not enough to claim it obscure. All of the words are within first 1k so\n> > > arguably if you have intermediate knowledge of (US) English you should\n> > > be familiar with all three.\n> > >\n> > > However, there is a different corpus that is much more relevant for the\n> > > git project:\n> > >\n> > > ✔ ~/git [master|…9]\n> > > 06:35 $ git grep affect | wc -l\n> > > 368\n> > > ✔ ~/git [master|…9]\n> > > 06:41 $ git grep effect | wc -l\n> > > 350\n> > > ✔ ~/git [master|…9]\n> > > 06:42 $ git grep impact | wc -l\n> > > 54\n> > >\n> > > There are only 54 instances of the word 'impact' in the git repository\n> > > which make up only 7.5%. It is feasible to eliminate those 54 instances\n> > > completely. In doing so you will make the git project use the same\n> > > wording consistently which makes it arguably more approachable to\n> > > non-native speakers with limited vocabulary. That states a clear metric\n> > > that is improved by such patch which also makes the reverse patch not\n> > > acceptable and prevents potential for infinite back-and-forth changing\n> > > from one synonym to the other.\n> > >\n> > > Bonus points if you add a test that prevents adding new instances of\n> > > 'impact' in the future.\n> >\n> > So you're saying you're OK with getting rid of all instances of\n> > \"impact\"? I'm for this, but insofar as I searched the code base, I\n> > only found the ones I'm changing in my patch (save for a couple that,\n> > as a previous reviewer mentioned, are included from other repos, so I\n> > left those).\n>\n> Yes, I am not opposed to the change in principle. You just failed to\n> provide any valid reason.\n>\n> Part of writing a patch is coming up with sound reasoning why the change\n> is desirable and stating that clearly in the commit message.\n>\n> I don't know if this reasoning is acceptable to git maintainers but at\n> least there is some real data it is based on.\n\nIt's useful to think of this commit via these perspectives:\n1. Do you think \"affect\" and \"impact\" are synonymous? Fine; this\nchange doesn't affect (no pun intended) you.\n2. Do you think \"impact\" is incorrectly used here? Great, because\nthat's what the commit is for.\n3. Do you think neither of the above are relevant, but want to get rid\nof the word \"impact\" completely from the Git repository specifically\nbecause of its relatively seldom use? That's great as well, since this\ncommit conveniently also addresses all instances of the word within\nthe code base that are stable/controlled by the Git repo (i.e., not\ndirectly imported from other code bases).\n\nThe advantage, fortunately, is that you can like any or all of these\nreasons, and we don't have to agree on which ones are the most\nimportant or relevant. The end result is the same: a less ambiguous\ncode base that makes everyone happy.\n"},{"id":"424421","messageId":"609cc4f5d05f_32932089@natae.notmuch","threadId":"55436","inReplyTo":"CAD2i4DB0Zt1snCS_iHZrRJ-woeY5eS-WpWpfdvWo2f5Mk5AY1w@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-13T06:19:33Z","receivedAt":"2021-05-13T06:20:00Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Varun Varada wrote:\n> The advantage, fortunately, is that you can like any or all of these\n> reasons, and we don't have to agree on which ones are the most\n> important or relevant. The end result is the same: a less ambiguous\n> code base that makes everyone happy.\n\nOr rather: doesn't make anyone unhappy.\n\n-- \nFelipe Contreras\n"},{"id":"424437","messageId":"20210513074622.GG8544@kitsune.suse.cz","threadId":"55436","inReplyTo":"609c2f98932f3_71bd120840@natae.notmuch","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-13T07:46:22Z","receivedAt":"2021-05-13T07:47:13Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, May 12, 2021 at 02:42:16PM -0500, Felipe Contreras wrote:\n> Michal Suchánek wrote:\n> > On Wed, May 12, 2021 at 12:32:16PM -0500, Felipe Contreras wrote:\n> > > Michal Suchánek wrote:\n> > > > Yes, I am not opposed to the change in principle.\n> > > \n> > > Good, so you accept you see nothing wrong with \"affect\".\n> > > \n> > > > You just failed to provide any valid reason.\n> > > \n> > > *In your opinion*.\n> > > \n> > > In my opinion the problems with the word \"impact\" have been clearly\n> > > explained.\n> > \n> > However, you only brought your personal opinion for the case that\n> > 'impact' is somehow wrong and should be changed.\n> \n> No I didn't. I used dictionary definitions to explain why it's wrong to\n> use it the way git uses both as a noun and a transitive verb.\n> \n> > 'impact' and 'affect' are equally good based on the past discussion so\n> > you will not bring change based on the 'badness' of 'impact'.\n> \n> That is your opinion, and its not shared by everyone.\n> \n> It's extremely disingenious to elevate your opinion as fact, especially\n> when this is precisely the thing we are discussing.\n> \n> > You claim that people who do not want to change 'impact' ignore your\n> > opinion.\n> \n> No I don't.\n> \n> I clam *you* pretend other opinions don't even exist.\n> \n> > Don't you equally ignore the opinion of people who think 'impact' is\n> > fine by insisting that the wording be changed based solely on your\n> > opinion?\n> \n> No, unlike you I acknowledge there's other people with different\n> opinions.\n> \n> However, that opinion is that \"impact\" is fine, *not* that \"affect\" is\n> bad.\n> \n> \n> If you and your wife are deciding what to eat for dinner, and you have\n> two opinions:\n> \n> 1. Whatever is fine\n> 2. I really would like pizza\n> \n> What do you think you should order?\n\nThat would be the situation if you comented on the patch adding 'impact'\nbefore it was merged.\n\nIf you want a dining metaphor for the current situation it would be more\nlike\n\n1. There are 100 people around the table eating lasagne\n2. You stand up and say you don't like lasagne and pizza should be\nbrought instead\n3. people say comeon, we already have lasagne. And are you so sure if we\nbring in pizza instead that nobody will object?\n4. you say nonsense, pizza is the best, nobody ever objected to it.\n5. you start banging your cutlery against the plate and shouting to\nbring the pizza already\n\nSounds very rude to me.\n\nBest regards\n\nMichal\n"},{"id":"424447","messageId":"609ce33fc57e7_5a820820@natae.notmuch","threadId":"55436","inReplyTo":"20210513074622.GG8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-13T08:28:47Z","receivedAt":"2021-05-13T08:28:56Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Wed, May 12, 2021 at 02:42:16PM -0500, Felipe Contreras wrote:\n> > If you and your wife are deciding what to eat for dinner, and you have\n> > two opinions:\n> > \n> > 1. Whatever is fine\n> > 2. I really would like pizza\n> > \n> > What do you think you should order?\n> \n> That would be the situation if you comented on the patch adding 'impact'\n> before it was merged.\n\nNo analogy is perfect.\n\n> If you want a dining metaphor for the current situation it would be more\n> like\n> \n> 1. There are 100 people around the table eating lasagne\n\nYou are starting wrong. *Nobody* is reading the word \"impact\" right now,\nand we are not going to swap the word in the middle of their reading.\n\nThis is a much worse analogy, and I seriously doubt you actually think\nthis remotely resembles the situation at hand.\n\n-- \nFelipe Contreras"},{"id":"424448","messageId":"CAFLLRpJeU3BFKmsGgFoKQRLCw-uGRRH1Ob7PZBHUEQu_Pqshgw@mail.gmail.com","threadId":"55436","inReplyTo":"20210513074622.GG8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Robert Coup","fromEmail":"robert.coup@koordinates.com","sentAt":"2021-05-13T08:55:42Z","receivedAt":"2021-05-13T08:56:01Z","isPatch":true,"sender":{"key":"robert.coup@koordinates.com","avatar":"https://gravatar.com/avatar/d1a87d63ffb562b791992d8a119ebbdd742e703109d23333ca3fca51306ee95c?d=mp&s=160"},"body":"Hi Michal,\n\nOn Thu, 13 May 2021 at 08:47, Michal Suchánek wrote:\n>\n> That would be the situation if you comented on the patch adding 'impact'\n> before it was merged.\n\nAs a lurker (and there are a lot more of us than people who email the\nlist), this comes across to me as veering well into bad faith. Because\nit wasn't picked up at the time it can never be improved? Code doesn't\nwork that way, neither should any other aspect of the project.\n\nNon-native English speakers outnumber native ones about 3:1 [1], and\neven within native English speaking countries there are variances in\ncommon vocabulary. This sort of stuff trips up non-native speakers\nthough (and the lack of rules in English makes it difficult enough) -\nwhy would we want to make understanding Git harder for people when\nthere's a simple improvement to be had?\n\nRob :)\n\n[1] https://en.wikipedia.org/wiki/English-speaking_world#cite_ref-Two_thousand_million_2-1\n"},{"id":"424454","messageId":"20210513094818.GH8544@kitsune.suse.cz","threadId":"55436","inReplyTo":"CAFLLRpJeU3BFKmsGgFoKQRLCw-uGRRH1Ob7PZBHUEQu_Pqshgw@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-13T09:48:18Z","receivedAt":"2021-05-13T09:48:24Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Thu, May 13, 2021 at 09:55:42AM +0100, Robert Coup wrote:\n> Hi Michal,\n> \n> On Thu, 13 May 2021 at 08:47, Michal Suchánek wrote:\n> >\n> > That would be the situation if you comented on the patch adding 'impact'\n> > before it was merged.\n> \n> As a lurker (and there are a lot more of us than people who email the\n> list), this comes across to me as veering well into bad faith. Because\n> it wasn't picked up at the time it can never be improved? Code doesn't\n> work that way, neither should any other aspect of the project.\n> \n> Non-native English speakers outnumber native ones about 3:1 [1], and\n> even within native English speaking countries there are variances in\n> common vocabulary. This sort of stuff trips up non-native speakers\n> though (and the lack of rules in English makes it difficult enough) -\n> why would we want to make understanding Git harder for people when\n> there's a simple improvement to be had?\n\nIndeed, and I even provided an argument why eliminating 'impact' in git\nwould likely improve the situation for non-native speakers. 'impact' is\nvery rarely used in git, and by eliminating it (which is completely\nfeasible) we reduce the vocabulary needed to read git documentation and\nmake it more consistent.\n\nYet Felipe insists that 'impact' is somehow generally bad word to use or\nthat it should be abolished solely because he finds it bad and nobody\nobjected to the alternative wording.\n\nOpinions on use of 'impact' differ both among the participants of this\ndiscussion and authorities like authors well-known dictionaries.\n\nIt looks like this is generally matter of stylistic preferences and\nopinions. That is even if there is some slight stylistic preference for\nnot using the word 'impact' it is very hard to prove such and then it is\nvery hard to request change based only on writing style preferences.\n\nThat's not to say it's impossible but Felipe chooses the option to\nrehash the same arguments ad nauseam without bringing clear and\nsubstantial arguments in favor of the change.\n\nThanks\n\nMichal\n"},{"id":"424456","messageId":"609cf89587279_1ec320836@natae.notmuch","threadId":"55436","inReplyTo":"20210513094818.GH8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-13T09:59:49Z","receivedAt":"2021-05-13T09:59:53Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> Yet Felipe insists that 'impact' is somehow generally bad word to use or\n> that it should be abolished solely because he finds it bad and nobody\n> objected to the alternative wording.\n\nThat is most certainly not what I said.\n\n-- \nFelipe Contreras"},{"id":"424457","messageId":"63dca3b2-1858-6708-5fb7-5a072b7b62f3@iee.email","threadId":"55436","inReplyTo":"CAD2i4DBj6fNvq=Lc3KiXJj5uBpteyKfEKp7ATOWrTE36KUeRww@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-13T10:40:17Z","receivedAt":"2021-05-13T10:40:25Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Varun,\n\nOn 05/04/2021 22:48, Varun Varada wrote:\n> There are a bunch of places in the code/docs which use the word \"impact\"\n> incorrectly. This is especially true of places where it says \"will not\n> impact\", which suggests that it might have an effect, albeit not as\n> strong of a one. This commit replaces all of these with their\n> appropriate alternative so that the docs not only does not use jargon,\n> but are also unambiguous.\n>\n> Signed-off-by: Varun Varada \n> ---\n> Documentation/MyFirstContribution.txt | 2 +-\n> Documentation/MyFirstObjectWalk.txt | 2 +-\n> Documentation/config/pack.txt | 2 +-\n> Documentation/git-fast-import.txt | 14 +++++++-------\n> Documentation/git-fetch.txt | 2 +-\n> .../technical/hash-function-transition.txt | 2 +-\n> Documentation/user-manual.txt | 4 ++--\n> advice.c | 2 +-\n> builtin/fast-import.c | 2 +-\n> builtin/pack-objects.c | 2 +-\n> compat/nedmalloc/malloc.c.h | 2 +-\n> contrib/coccinelle/README | 2 +-\n> dir.c | 2 +-\n> t/perf/p5550-fetch-tags.sh | 2 +-\n> t/t0008-ignores.sh | 2 +-\n> t/t0303-credential-external.sh | 2 +-\n> t/t2020-checkout-detach.sh | 4 ++--\n> t/t4013-diff-various.sh | 2 +-\n> t/t5000-tar-tree.sh | 2 +-\n> t/test-lib-functions.sh | 2 +-\n> 20 files changed, 28 insertions(+), 28 deletions(-)\n\nI've seen the rather extended discussion about word choice. However Can \nI suggest an alternative split of the patch?\n\nIf the patch is split between:\n1. Test shells\n2. Code comments\n3. Manual pages\n4. Guides and How to's.\n  then it should be possible to focus on the precision aspects first, \nand only later get into the imprecision of modern colloquial English. \nFor the manual page changes, having a direct link to a test shell or \ncode comment change would provide important support to the clarification \nof any precision aspects of the changes.\n\nPhilip\n(I'll be off-line for a few days)\nSlice the melon before eating.\n\n> diff --git a/Documentation/MyFirstContribution.txt\n> b/Documentation/MyFirstContribution.txt\n> index af0a9da62e..8372a7e59e 100644\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git\n> how to show it in the general\n> command list shown by `git help git` or `git help -a`, which is generated from\n> `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> line above it in alphabetical order. Now, we can add some attributes about the\n> -command which impacts where it shows up in the aforementioned help\n> commands. The\n> +command which affects where it shows up in the aforementioned help\n> commands. The\n> top of `command-list.txt` shares some information about what each attribute\n> means; in those help pages, the commands are sorted according to these\n> attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n> diff --git a/Documentation/MyFirstObjectWalk.txt\n> b/Documentation/MyFirstObjectWalk.txt\n> index 2d10eea7a9..fd5bb8fb7d 100644\n> --- a/Documentation/MyFirstObjectWalk.txt\n> +++ b/Documentation/MyFirstObjectWalk.txt\n> @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:\n> By running your walk with and without the filter, you should find\n> that the total\n> object count in each case is identical. You can also time each invocation of\n> the `walken` subcommand, with and without `omitted` being passed in, to confirm\n> -to yourself the runtime impact of tracking all omitted objects.\n> +to yourself the runtime effect of tracking all omitted objects.\n>\n> === Changing the Order\n>\n> diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt\n> index 3da4ea98e2..00fcc9d7c7 100644\n> --- a/Documentation/config/pack.txt\n> +++ b/Documentation/config/pack.txt\n> @@ -55,7 +55,7 @@ pack.deltaCacheSize::\n> This cache is used to speed up the writing object phase by not\n> having to recompute the final delta result once the best match\n> for all objects is found. Repacking large repositories on machines\n> - which are tight with memory might be badly impacted by this though,\n> + which are tight with memory might be badly affected by this though,\n> especially if this cache pushes the system into swapping.\n> A value of 0 means no limit. The smallest size of 1 byte may be\n> used to virtually disable this cache. Defaults to 256 MiB.\n> diff --git a/Documentation/git-fast-import.txt\n> b/Documentation/git-fast-import.txt\n> index 39cfa05b28..c6d8e4e1d7 100644\n> --- a/Documentation/git-fast-import.txt\n> +++ b/Documentation/git-fast-import.txt\n> @@ -58,7 +58,7 @@ OPTIONS\n> allowing fast-import to access the filesystem outside of the\n> repository). These options are disabled by default, but can be\n> allowed by providing this option on the command line. This\n> - currently impacts only the `export-marks`, `import-marks`, and\n> + currently affects only the `export-marks`, `import-marks`, and\n> `import-marks-if-exists` feature commands.\n> +\n> Only enable this option if you trust the program generating the\n> @@ -687,7 +687,7 @@ that contains SP the path must be quoted.\n>\n> A `filecopy` command takes effect immediately. Once the source\n> location has been copied to the destination any future commands\n> -applied to the source location will not impact the destination of\n> +applied to the source location will not affect the destination of\n> the copy.\n>\n> `filerename`\n> @@ -708,7 +708,7 @@ that contains SP the path must be quoted.\n> A `filerename` command takes effect immediately. Once the source\n> location has been renamed to the destination any future commands\n> applied to the source location will create new files there and not\n> -impact the destination of the rename.\n> +affect the destination of the rename.\n>\n> Note that a `filerename` is the same as a `filecopy` followed by a\n> `filedelete` of the source location. There is a slight performance\n> @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used\n> to be required).\n> ~~~~~~~~~~\n> Causes fast-import to print the entire `progress` line unmodified to\n> its standard output channel (file descriptor 1) when the command is\n> -processed from the input stream. The command otherwise has no impact\n> +processed from the input stream. The command otherwise has no effect\n> on the current import, or on any of fast-import's internal state.\n>\n> ....\n> @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.\n> ~~~~~~~~~~\n> Causes fast-import to print the SHA-1 corresponding to a mark to\n> stdout or to the file descriptor previously arranged with the\n> -`--cat-blob-fd` argument. The command otherwise has no impact on the\n> +`--cat-blob-fd` argument. The command otherwise has no effect on the\n> current import; its purpose is to retrieve SHA-1s that later commits\n> might want to refer to in their commit messages.\n>\n> @@ -1050,7 +1050,7 @@ this output safely.\n> ~~~~~~~~~~\n> Causes fast-import to print a blob to a file descriptor previously\n> arranged with the `--cat-blob-fd` argument. The command otherwise\n> -has no impact on the current import; its main purpose is to\n> +has no effect on the current import; its main purpose is to\n> retrieve blobs that may be in fast-import's memory but not\n> accessible from the target repository.\n>\n> @@ -1366,7 +1366,7 @@ code considerably.\n>\n> The branch LRU builtin to fast-import tends to behave very well, and the\n> cost of activating an inactive branch is so low that bouncing around\n> -between branches has virtually no impact on import performance.\n> +between branches has virtually no effect on import performance.\n>\n> Handling Renames\n> ~~~~~~~~~~~~~~~~\n> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> index 9067c2079e..01cf3b3d16 100644\n> --- a/Documentation/git-fetch.txt\n> +++ b/Documentation/git-fetch.txt\n> @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.\n> If left to accumulate, these stale references might make performance\n> worse on big and busy repos that have a lot of branch churn, and\n> e.g. make the output of commands like `git branch -a --contains\n> -` needlessly verbose, as well as impacting anything else\n> +` needlessly verbose, as well as affecting anything else\n> that'll work with the complete set of known references.\n>\n> These remote-tracking references can be deleted as a one-off with\n> diff --git a/Documentation/technical/hash-function-transition.txt\n> b/Documentation/technical/hash-function-transition.txt\n> index 7c1630bf83..f4296faffc 100644\n> --- a/Documentation/technical/hash-function-transition.txt\n> +++ b/Documentation/technical/hash-function-transition.txt\n> @@ -42,7 +42,7 @@ mitigations.\n>\n> If SHA-1 and its variants were to be truly broken, Git's hash function\n> could not be considered cryptographically secure any more. This would\n> -impact the communication of hash values because we could not trust\n> +affect the communication of hash values because we could not trust\n> that a given hash value represented the known good version of content\n> that the speaker intended.\n>\n> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> index fd480b8645..33c60c49d7 100644\n> --- a/Documentation/user-manual.txt\n> +++ b/Documentation/user-manual.txt\n> @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.\n>\n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> -state without impacting any branches by performing another switch.\n> +state without affecting any branches by performing another switch.\n>\n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command again. Example:\n> @@ -1189,7 +1189,7 @@ their histories forked. The work tree is\n> overwritten by the result of\n> the merge when this combining is done cleanly, or overwritten by a\n> half-merged results when this combining results in conflicts.\n> Therefore, if you have uncommitted changes touching the same files as\n> -the ones impacted by the merge, Git will refuse to proceed. Most of\n> +the ones affected by the merge, Git will refuse to proceed. Most of\n> the time, you will want to commit your changes before you can merge,\n> and if you don't, then linkgit:git-stash[1] can take these changes\n> away while you're doing the merge, and reapply them afterwards.\n> diff --git a/advice.c b/advice.c\n> index 164742305f..9cbbb824a9 100644\n> --- a/advice.c\n> +++ b/advice.c\n> @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)\n> \"\\n\"\n> \"You are in 'detached HEAD' state. You can look around, make experimental\\n\"\n> \"changes and commit them, and you can discard any commits you make in this\\n\"\n> - \"state without impacting any branches by switching back to a branch.\\n\"\n> + \"state without affecting any branches by switching back to a branch.\\n\"\n> \"\\n\"\n> \"If you want to create a new branch to retain commits you create, you may\\n\"\n> \"do so (now or later) by using -c with the switch command. Example:\\n\"\n> diff --git a/builtin/fast-import.c b/builtin/fast-import.c\n> index 3afa81cf9a..24f362d2f4 100644\n> --- a/builtin/fast-import.c\n> +++ b/builtin/fast-import.c\n> @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,\n> const char *prefix)\n> * We don't parse most options until after we've seen the set of\n> * \"feature\" lines at the start of the stream (which allows the command\n> * line to override stream data). But we must do an early parse of any\n> - * command-line options that impact how we interpret the feature lines.\n> + * command-line options that affect how we interpret the feature lines.\n> */\n> for (i = 1; i < argc; i++) {\n> const char *arg = argv[i];\n> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\n> index 525c2d8552..749bbca241 100644\n> --- a/builtin/pack-objects.c\n> +++ b/builtin/pack-objects.c\n> @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)\n> /*\n> * Mark ourselves as active and see if the next step causes\n> * us to cycle to another active object. It's important to do\n> - * this _before_ we loop, because it impacts where we make the\n> + * this _before_ we loop, because it affects where we make the\n> * cut, and thus how our total_depth counter works.\n> * E.g., We may see a partial loop like:\n> *\n> diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h\n> index 814845d4b3..de13121d76 100644\n> --- a/compat/nedmalloc/malloc.c.h\n> +++ b/compat/nedmalloc/malloc.c.h\n> @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);\n> #endif /* (FOOTERS && !INSECURE) */\n>\n>\n> -/* In gcc, use __builtin_expect to minimize impact of checks */\n> +/* In gcc, use __builtin_expect to minimize affect of checks */\n> #if !INSECURE\n> #if defined(__GNUC__) && __GNUC__ >= 3\n> #define RTCHECK(e) __builtin_expect(e, 1)\n> diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README\n> index f0e80bd7f0..92979ec770 100644\n> --- a/contrib/coccinelle/README\n> +++ b/contrib/coccinelle/README\n> @@ -40,4 +40,4 @@ There are two types of semantic patches:\n> are ignored for checks, and can be applied using 'make coccicheck-pending'.\n>\n> This allows to expose plans of pending large scale refactorings without\n> - impacting the bad pattern checks.\n> + affecting the bad pattern checks.\n> diff --git a/dir.c b/dir.c\n> index 3474e67e8f..235e26a90e 100644\n> --- a/dir.c\n> +++ b/dir.c\n> @@ -2144,7 +2144,7 @@ static enum path_treatment\n> treat_path_fast(struct dir_struct *dir,\n> /*\n> * We get path_recurse in the first run when\n> * directory_exists_in_index() returns index_nonexistent. We\n> - * are sure that new changes in the index does not impact the\n> + * are sure that new changes in the index does not affect the\n> * outcome. Return now.\n> */\n> return path_recurse;\n> diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh\n> index d0e0e019ea..1fcb98443c 100755\n> --- a/t/perf/p5550-fetch-tags.sh\n> +++ b/t/perf/p5550-fetch-tags.sh\n> @@ -8,7 +8,7 @@ follows.\n>\n> The parent repository has a large number of tags which are disconnected from\n> the rest of history. That makes them candidates for tag-following, but we never\n> -actually grab them (and thus they will impact each subsequent fetch).\n> +actually grab them (and thus they will affect each subsequent fetch).\n>\n> The child repository is a clone of parent, without the tags, and is at least\n> one commit behind the parent (meaning that we will fetch one object and then\n> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh\n> index a594b4aa7d..95daba4000 100755\n> --- a/t/t0008-ignores.sh\n> +++ b/t/t0008-ignores.sh\n> @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '\n> # test standard ignores\n>\n> # First make sure that the presence of a file in the working tree\n> -# does not impact results, but that the presence of a file in the\n> +# does not affect results, but that the presence of a file in the\n> # index does unless the --no-index option is used.\n>\n> for subdir in '' 'a/'\n> diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh\n> index f028fd1418..a9348f655a 100755\n> --- a/t/t0303-credential-external.sh\n> +++ b/t/t0303-credential-external.sh\n> @@ -41,7 +41,7 @@ test -z \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\" ||\n> eval \"$GIT_TEST_CREDENTIAL_HELPER_SETUP\"\n>\n> # clean before the test in case there is cruft left\n> -# over from a previous run that would impact results\n> +# over from a previous run that would affect results\n> helper_test_clean \"$GIT_TEST_CREDENTIAL_HELPER\"\n>\n> helper_test \"$GIT_TEST_CREDENTIAL_HELPER\"\n> diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh\n> index bc46713a43..568c258c5a 100755\n> --- a/t/t2020-checkout-detach.sh\n> +++ b/t/t2020-checkout-detach.sh\n> @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints\n> no SHA-1 ellipsis when not as\n>\n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> - state without impacting any branches by switching back to a branch.\n> + state without affecting any branches by switching back to a branch.\n>\n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command. Example:\n> @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does\n> print SHA-1 ellipsis when asked\n>\n> You are in 'detached HEAD' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> - state without impacting any branches by switching back to a branch.\n> + state without affecting any branches by switching back to a branch.\n>\n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -c with the switch command. Example:\n> diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> index 6cca8b84a6..97365a7786 100755\n> --- a/t/t4013-diff-various.sh\n> +++ b/t/t4013-diff-various.sh\n> @@ -109,7 +109,7 @@ test_expect_success setup '\n> git checkout -f master &&\n>\n> # Same merge as master, but with parents reversed. Hide it in a\n> - # pseudo-ref to avoid impacting tests with --all.\n> + # pseudo-ref to avoid affecting tests with --all.\n> commit=$(echo reverse |\n> git commit-tree -p master^2 -p master^1 master^{tree}) &&\n> git update-ref REVERSE $commit &&\n> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\n> index 7204799a0b..33a6efce2f 100755\n> --- a/t/t5000-tar-tree.sh\n> +++ b/t/t5000-tar-tree.sh\n> @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '\n> # Pull the size and date of each entry in a tarfile using the system tar.\n> #\n> # We'll pull out only the year from the date; that avoids any question of\n> -# timezones impacting the result (as long as we keep our test times away from a\n> +# timezones affecting the result (as long as we keep our test times away from a\n> # year boundary; our reference times are all in August).\n> #\n> # The output of tar_info is expected to be \" \", both in decimal. It\n> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\n> index 6348e8d733..ff65f86f50 100644\n> --- a/t/test-lib-functions.sh\n> +++ b/t/test-lib-functions.sh\n> @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {\n> }\n>\n> # Like \"env FOO=BAR some-program\", but run inside a subshell, which means\n> -# it also works for shell functions (though those functions cannot impact\n> +# it also works for shell functions (though those functions cannot affect\n> # the environment outside of the test_env invocation).\n> test_env () {\n> (\n\n"},{"id":"425598","messageId":"CAD2i4DDY1z1ZNigRfVog1205hKBk+U5KfinzXCk-2mkaYy4cjQ@mail.gmail.com","threadId":"55436","inReplyTo":"20210513094818.GH8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-05-26T23:49:58Z","receivedAt":"2021-05-26T23:50:12Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Thu, 13 May 2021 at 04:48, Michal Suchánek wrote:\n> Yet Felipe insists that 'impact' is somehow generally bad word to use or\n> that it should be abolished solely because he finds it bad and nobody\n> objected to the alternative wording.\n>\n> Opinions on use of 'impact' differ both among the participants of this\n> discussion and authorities like authors well-known dictionaries.\n>\n> It looks like this is generally matter of stylistic preferences and\n> opinions. That is even if there is some slight stylistic preference for\n> not using the word 'impact' it is very hard to prove such and then it is\n> very hard to request change based only on writing style preferences.\n\nThe argument is not that it is generally a bad word to use, but that\nit is generally bad to use words when they don't mean what one thinks\nthey mean, especially when all evidence says otherwise.\n\nAll major dictionaries define \"impact\" as \"a strong effect\" or \"to\naffect strongly\". This is not style, but semantics. In the same way\nthat \"per se\" being used to mean \"necessarily\" is not a style issue,\nusing \"impact\" to mean \"an effect\" or \"to affect\" is not a style\nissue.\n\nAs has been stated already, the clear and substantial argument for\nthis change is that it reduces the confusion that arises from\nimproperly using the word \"impact\" in the instances without any loss\nor compromise in meaning. That is a clear win.\n"},{"id":"425599","messageId":"CAD2i4DAbBiVRo2Zk_cSYbgXGmm0SMUJZxSqYWhQr3tjwHxCYHQ@mail.gmail.com","threadId":"55436","inReplyTo":"63dca3b2-1858-6708-5fb7-5a072b7b62f3@iee.email","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-05-26T23:52:34Z","receivedAt":"2021-05-26T23:52:50Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Thu, 13 May 2021 at 05:40, Philip Oakley wrote:\n>\n> Hi Varun,\n>\n>\n> I've seen the rather extended discussion about word choice. However Can\n> I suggest an alternative split of the patch?\n>\n> If the patch is split between:\n> 1. Test shells\n> 2. Code comments\n> 3. Manual pages\n> 4. Guides and How to's.\n> then it should be possible to focus on the precision aspects first,\n> and only later get into the imprecision of modern colloquial English.\n> For the manual page changes, having a direct link to a test shell or\n> code comment change would provide important support to the clarification\n> of any precision aspects of the changes.\n\nI'd be happy to split it, but I'm not sure I follow what you mean by\n\"precision aspects\".\n"},{"id":"425663","messageId":"571aa879-4f34-751d-b2e7-33d4042656c1@iee.email","threadId":"55436","inReplyTo":"CAD2i4DAbBiVRo2Zk_cSYbgXGmm0SMUJZxSqYWhQr3tjwHxCYHQ@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-27T11:20:35Z","receivedAt":"2021-05-27T11:20:36Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 27/05/2021 00:52, Varun Varada wrote:\n> On Thu, 13 May 2021 at 05:40, Philip Oakley wrote:\n>> Hi Varun,\n>>\n>>\n>> I've seen the rather extended discussion about word choice. However Can\n>> I suggest an alternative split of the patch?\n>>\n>> If the patch is split between:\n>> 1. Test shells\n>> 2. Code comments\n>> 3. Manual pages\n>> 4. Guides and How to's.\n>> then it should be possible to focus on the precision aspects first,\n>> and only later get into the imprecision of modern colloquial English.\n>> For the manual page changes, having a direct link to a test shell or\n>> code comment change would provide important support to the clarification\n>> of any precision aspects of the changes.\n> I'd be happy to split it, but I'm not sure I follow what you mean by\n> \"precision aspects\".\nHi, I was using precision in a similar way to the accuracy/precision\nsense that you had highlighted about affect/effect not really being\ninterchangeable (i.e. my 'precision' is similarly inexact;-).\n\nYou are right that there is a distinct difference between affect/effect\nfor the grammar pedants and that in the vernacular (common) usage,\nbecause of the many dialects and vocalisation here in UK (and likely the\nAmericas), many folk ignore the spelling (esp if spoken;-) and just look\nfor context.\n\nMy suggestion was to start with just the test/code comments where it is\nlikely easier to identify and describe the affect/effect mistakes\n(accurately and precisely). By splitting the patches into separate Test\nand Code changes each review gets smaller and easier.\n\nThen, for each of the test and code patch, see if there is a (~exactly)\nmatching issue in the documentation. These can then (hopefully) easily\nbe justified by reference to their code/test change.\n\nThis should leave a few (~small amount ;-) of residual affect/effect\npotential changes to be discussed/argued over.\n\nPhilip\n\n[the _average_ number of residual changes won't be an integer, so maybe\nit is a small amount of changes]\n\n"},{"id":"425665","messageId":"20210527114629.GD8544@kitsune.suse.cz","threadId":"55436","inReplyTo":"CAD2i4DDY1z1ZNigRfVog1205hKBk+U5KfinzXCk-2mkaYy4cjQ@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-27T11:46:29Z","receivedAt":"2021-05-27T11:46:33Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, May 26, 2021 at 06:49:58PM -0500, Varun Varada wrote:\n> On Thu, 13 May 2021 at 04:48, Michal Suchánek wrote:\n> > Yet Felipe insists that 'impact' is somehow generally bad word to use or\n> > that it should be abolished solely because he finds it bad and nobody\n> > objected to the alternative wording.\n> >\n> > Opinions on use of 'impact' differ both among the participants of this\n> > discussion and authorities like authors well-known dictionaries.\n> >\n> > It looks like this is generally matter of stylistic preferences and\n> > opinions. That is even if there is some slight stylistic preference for\n> > not using the word 'impact' it is very hard to prove such and then it is\n> > very hard to request change based only on writing style preferences.\n> \n> The argument is not that it is generally a bad word to use, but that\n> it is generally bad to use words when they don't mean what one thinks\n> they mean, especially when all evidence says otherwise.\n\nNot all evidence. There are people who think the use is fine.\n\n> \n> All major dictionaries define \"impact\" as \"a strong effect\" or \"to\n> affect strongly\". This is not style, but semantics. In the same way\n\nNot all dictionaries, actually. And when there is no meaningful\ndifference between \"strong efffect\" and \"effect\" using word that means\none or the other is just style.`\n\n> that \"per se\" being used to mean \"necessarily\" is not a style issue,\n> using \"impact\" to mean \"an effect\" or \"to affect\" is not a style\n> issue.\n> \n> As has been stated already, the clear and substantial argument for\n> this change is that it reduces the confusion that arises from\n> improperly using the word \"impact\" in the instances without any loss\n\nThere is no final authority on 'correct' word use in English.\nAuthorities and readers disagree. In some cases local language variation\ndisagrees so completely that no use is correct everywhere - eg. color vs\ncolour.\n\nWe should learn to work together with people that use different\nvariant of the language rather than insist that the variant that I or my\nteacher uses is the only correct one and everyone else should use it.\n\nThanks\n\nMichal\n"},{"id":"425677","messageId":"60afa7d9d4ca_2056d208d9@natae.notmuch","threadId":"55436","inReplyTo":"20210527114629.GD8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-27T14:08:25Z","receivedAt":"2021-05-27T14:09:13Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Wed, May 26, 2021 at 06:49:58PM -0500, Varun Varada wrote:\n> > On Thu, 13 May 2021 at 04:48, Michal Suchánek wrote:\n> > > Yet Felipe insists that 'impact' is somehow generally bad word to use or\n> > > that it should be abolished solely because he finds it bad and nobody\n> > > objected to the alternative wording.\n> > >\n> > > Opinions on use of 'impact' differ both among the participants of this\n> > > discussion and authorities like authors well-known dictionaries.\n> > >\n> > > It looks like this is generally matter of stylistic preferences and\n> > > opinions. That is even if there is some slight stylistic preference for\n> > > not using the word 'impact' it is very hard to prove such and then it is\n> > > very hard to request change based only on writing style preferences.\n> > \n> > The argument is not that it is generally a bad word to use, but that\n> > it is generally bad to use words when they don't mean what one thinks\n> > they mean, especially when all evidence says otherwise.\n> \n> Not all evidence. There are people who think the use is fine.\n\nWhat people think is not evidence.\n\nThere's people who think the Earth is flat.\n\n> > All major dictionaries define \"impact\" as \"a strong effect\" or \"to\n> > affect strongly\". This is not style, but semantics. In the same way\n> \n> Not all dictionaries, actually.\n\nYou don't need all dictionaries.\n\nIf 50% of trials show a drug is safe, and 50% show it's not, you don't\napprove bit because \"not all say say it's unsafe\".\n\nIf there's evidence that A is bad, you should consider avoiding A,\nespecially when you have B, and you have *zero* evidence showing B is\nbad.\n\n> > that \"per se\" being used to mean \"necessarily\" is not a style issue,\n> > using \"impact\" to mean \"an effect\" or \"to affect\" is not a style\n> > issue.\n> > \n> > As has been stated already, the clear and substantial argument for\n> > this change is that it reduces the confusion that arises from\n> > improperly using the word \"impact\" in the instances without any loss\n> \n> There is no final authority on 'correct' word use in English.\n\nYou don't need a final authority.\n\nThere is evidence that A is problematic.\n\n> We should learn to work together with people that use different\n> variant of the language rather than insist that the variant that I or my\n> teacher uses is the only correct one and everyone else should use it.\n\nExcept one variant is problematic, and the other is not.\n\n\nDo you have *ANY* evidence that shows a problem with \"effect\"?\n\n-- \nFelipe Contreras"},{"id":"425680","messageId":"20210527143541.GH8544@kitsune.suse.cz","threadId":"55436","inReplyTo":"60afa7d9d4ca_2056d208d9@natae.notmuch","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-05-27T14:35:41Z","receivedAt":"2021-05-27T14:35:46Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Thu, May 27, 2021 at 09:08:25AM -0500, Felipe Contreras wrote:\n> Michal Suchánek wrote:\n> > On Wed, May 26, 2021 at 06:49:58PM -0500, Varun Varada wrote:\n> > > On Thu, 13 May 2021 at 04:48, Michal Suchánek wrote:\n> > > > Yet Felipe insists that 'impact' is somehow generally bad word to use or\n> > > > that it should be abolished solely because he finds it bad and nobody\n> > > > objected to the alternative wording.\n> > > >\n> > > > Opinions on use of 'impact' differ both among the participants of this\n> > > > discussion and authorities like authors well-known dictionaries.\n> > > >\n> > > > It looks like this is generally matter of stylistic preferences and\n> > > > opinions. That is even if there is some slight stylistic preference for\n> > > > not using the word 'impact' it is very hard to prove such and then it is\n> > > > very hard to request change based only on writing style preferences.\n> > > \n> > > The argument is not that it is generally a bad word to use, but that\n> > > it is generally bad to use words when they don't mean what one thinks\n> > > they mean, especially when all evidence says otherwise.\n> > \n> > Not all evidence. There are people who think the use is fine.\n> \n> What people think is not evidence.\n> \n> There's people who think the Earth is flat.\n\nAnd there's people who think it's not ok to use 'impact' as synonym for\neffect/affect, too.\n\n> \n> > > All major dictionaries define \"impact\" as \"a strong effect\" or \"to\n> > > affect strongly\". This is not style, but semantics. In the same way\n> > \n> > Not all dictionaries, actually.\n> \n> You don't need all dictionaries.\n> \n> If 50% of trials show a drug is safe, and 50% show it's not, you don't\n> approve bit because \"not all say say it's unsafe\".\n> \n> If there's evidence that A is bad, you should consider avoiding A,\n> especially when you have B, and you have *zero* evidence showing B is\n> bad.\n\nIndeed, but what the dictionaries provide is a definition.\n\nBased on the definition some people think it's not OK, and some people\nthink it's OK.\n\nThat's only opinion, not evidence.\n> \n> > > that \"per se\" being used to mean \"necessarily\" is not a style issue,\n> > > using \"impact\" to mean \"an effect\" or \"to affect\" is not a style\n> > > issue.\n> > > \n> > > As has been stated already, the clear and substantial argument for\n> > > this change is that it reduces the confusion that arises from\n> > > improperly using the word \"impact\" in the instances without any loss\n> > \n> > There is no final authority on 'correct' word use in English.\n> \n> You don't need a final authority.\n> \n> There is evidence that A is problematic.\n\nSo we should stop using words that have different spelling in British\nand American English because no matter what spelling you choose somebody\ncan find it 'problematic'?\n\n> \n> > We should learn to work together with people that use different\n> > variant of the language rather than insist that the variant that I or my\n> > teacher uses is the only correct one and everyone else should use it.\n> \n> Except one variant is problematic, and the other is not.\n> \n> \n> Do you have *ANY* evidence that shows a problem with \"effect\"?\n\nI find problem with the proposition that 'impact' should be replaced\nwith 'effect' based solely on the opinion that use of 'impact' is\nsomehow inferior.\n\nThis will bring in reviews that focus on hairsplitting when the\nformulation with 'impact' reads better than 'effect' and where the\nchange does not make it read any better so it should not be changed.\n\nIt also brings in reviews of the sort that simply say that use of\n'impact' is OK, and there is no need to change.\n\nYou can reason the change in different, more objective ways. You\nrefuse and insist that people acknowledge that the use of 'impact' is\nwrong. It is not universally true in the same way that writing neither\n'color' nor 'colour' is not universally correct.\n\nAlso I have so far not seen any real evidence that 'impact' is in fact\nused incorrectly, only some opinions and reference to a style guide.\n\nSo if you want to compare to physicians and drug trials how many\ndouble-blind studies on the effect of the use of word 'impact' can you\nrefer to?\n\nThanks\n\nMichal\n\n\n"},{"id":"425691","messageId":"60afcc4169433_2653020844@natae.notmuch","threadId":"55436","inReplyTo":"20210527143541.GH8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-27T16:43:45Z","receivedAt":"2021-05-27T16:43:51Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Thu, May 27, 2021 at 09:08:25AM -0500, Felipe Contreras wrote:\n> > Do you have *ANY* evidence that shows a problem with \"effect\"?\n> \n> I find problem with the proposition that 'impact' should be replaced\n> with 'effect'...\n\nDo not avoid the question.\n\nAnswer the question being asked.\n\n-- \nFelipe Contreras"},{"id":"427196","messageId":"CAD2i4DC0zH8WQvfZiHJA7f+DXubZjG6fKSuMbXdaztDC_PU4ZA@mail.gmail.com","threadId":"55436","inReplyTo":"20210527143541.GH8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Varun Varada","fromEmail":"varuncvarada@gmail.com","sentAt":"2021-06-12T23:13:02Z","receivedAt":"2021-06-12T23:13:15Z","isPatch":true,"sender":{"key":"varuncvarada@gmail.com","avatar":null},"body":"On Thu, 27 May 2021 at 09:35, Michal Suchánek wrote:\n>\n> > > Not all evidence. There are people who think the use is fine.\n> >\n> > What people think is not evidence.\n> >\n> > There's people who think the Earth is flat.\n>\n> And there's people who think it's not ok to use 'impact' as synonym for\n> effect/affect, too.\n\nThis is not because they *think* this, but because it's demonstrably\ntrue. The words are not synonyms according to any reputable\ndictionaries, as shown already.\n\n>\n> Indeed, but what the dictionaries provide is a definition.\n>\n> Based on the definition some people think it's not OK, and some people\n> think it's OK.\n>\n> That's only opinion, not evidence.\n\nHence, the dictionary definitions, which are evidence. If people are\nconfused as to what the words within the definition mean, they can\nthen recursively refer to the definitions of those words within the\ndefinition. Unless you're implying that most of the dictionaries\nreferenced here are prescriptive (which they're not), then what the\ndictionaries say are the definitions of words are results of the\nlinguists of those dictionaries going around and documenting what the\nwords mean, with ample historical and etymological evidence to back\nit.\n\nPeople having opinions about said definitions is, like you said, only\nopinion and not evidence. All evidence points to the fact that the\nwords are not synonyms.\n\n> >\n> > > > that \"per se\" being used to mean \"necessarily\" is not a style issue,\n> > > > using \"impact\" to mean \"an effect\" or \"to affect\" is not a style\n> > > > issue.\n> > > >\n> > > > As has been stated already, the clear and substantial argument for\n> > > > this change is that it reduces the confusion that arises from\n> > > > improperly using the word \"impact\" in the instances without any loss\n> > >\n> > > There is no final authority on 'correct' word use in English.\n\nYes, there essentially is. It's called a dictionary. If you don't\nrespect the value of dictionaries, you're tacitly claiming that anyone\ncan use words in any which way they want and they would be correct in\ndoing so. E.g., someone can use \"hello\" to mean \"goodbye\" and be\ncorrect because there's no so-called authority.\n\n> >\n> > You don't need a final authority.\n> >\n> > There is evidence that A is problematic.\n>\n> So we should stop using words that have different spelling in British\n> and American English because no matter what spelling you choose somebody\n> can find it 'problematic'?\n\nNo, because practically every dictionary on the planet acknowledges\nwhen spelling differences exist and which spellings correspond to\nidentical words (e.g., \"colour\" and \"color\" mean the same thing in all\ncontexts).\n\n>\n> >\n> > > We should learn to work together with people that use different\n> > > variant of the language rather than insist that the variant that I or my\n> > > teacher uses is the only correct one and everyone else should use it.\n> >\n> > Except one variant is problematic, and the other is not.\n> >\n> >\n> > Do you have *ANY* evidence that shows a problem with \"effect\"?\n>\n> I find problem with the proposition that 'impact' should be replaced\n> with 'effect' based solely on the opinion that use of 'impact' is\n> somehow inferior.\n\nIt's not \"somehow inferior\". No one is waving their hands arbitrarily;\nit's already been discussed precisely how the word is inappropriate.\n\n>\n> This will bring in reviews that focus on hairsplitting when the\n> formulation with 'impact' reads better than 'effect' and where the\n> change does not make it read any better so it should not be changed.\n>\n> It also brings in reviews of the sort that simply say that use of\n> 'impact' is OK, and there is no need to change.\n\nThat's an \"if\". This, however, is a situation where multiple people\nhave already voiced concerns about it being a problem. And it's not\nhairsplitting; not at all, in fact. It's genuinely confusing.\n\n>\n> You can reason the change in different, more objective ways. You\n> refuse and insist that people acknowledge that the use of 'impact' is\n> wrong. It is not universally true in the same way that writing neither\n> 'color' nor 'colour' is not universally correct.\n\nIt's clear by now that you are not fundamentally against the change\neither, but are merely arguing about what reason one should \"report to\nthe world\" for why this change was made. I've already stated that we\ndon't need to agree on what the reason is since the end result will be\nthe same. Please stop this pedantic and frankly pointless discussion\nabout a hypothetical about what future people might think; it's\nbecoming exhausting. This is a change that (evidently) multiple people\nin the present have brought up as an issue, so it needs solving now.\n\n> Also I have so far not seen any real evidence that 'impact' is in fact\n> used incorrectly, only some opinions and reference to a style guide.\n\nIf you don't consider dictionaries and style guides to be evidence,\nthen I don't know what counts as evidence.\n\nVarun\n"},{"id":"427229","messageId":"20210613114007.GF8544@kitsune.suse.cz","threadId":"55436","inReplyTo":"CAD2i4DC0zH8WQvfZiHJA7f+DXubZjG6fKSuMbXdaztDC_PU4ZA@mail.gmail.com","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-06-13T11:40:07Z","receivedAt":"2021-06-13T11:41:27Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Sat, Jun 12, 2021 at 06:13:02PM -0500, Varun Varada wrote:\n> On Thu, 27 May 2021 at 09:35, Michal Suchánek wrote:\n> >\n> > > > Not all evidence. There are people who think the use is fine.\n> > >\n> > > What people think is not evidence.\n> > >\n> > > There's people who think the Earth is flat.\n> >\n> > And there's people who think it's not ok to use 'impact' as synonym for\n> > effect/affect, too.\n> \n> This is not because they *think* this, but because it's demonstrably\n> true. The words are not synonyms according to any reputable\n> dictionaries, as shown already.\n> \n> >\n> > Indeed, but what the dictionaries provide is a definition.\n> >\n> > Based on the definition some people think it's not OK, and some people\n> > think it's OK.\n> >\n> > That's only opinion, not evidence.\n> \n> Hence, the dictionary definitions, which are evidence. If people are\n\nThe dictionaries provide definition, not usage guidelines.\n\nFabricating usage guildelines from sources that do not provide them is\nopinion, not evidence.\n\n> confused as to what the words within the definition mean, they can\n\nTwo people. That's called 'anecdotal evidence'. You will find anecdotal\nevidence in favor of pretty much anything possible, that does not mean\nit's in any way common.\n\n> \n> > >\n> > > > > that \"per se\" being used to mean \"necessarily\" is not a style issue,\n> > > > > using \"impact\" to mean \"an effect\" or \"to affect\" is not a style\n> > > > > issue.\n> > > > >\n> > > > > As has been stated already, the clear and substantial argument for\n> > > > > this change is that it reduces the confusion that arises from\n> > > > > improperly using the word \"impact\" in the instances without any loss\n> > > >\n> > > > There is no final authority on 'correct' word use in English.\n> \n> Yes, there essentially is. It's called a dictionary. If you don't\n> respect the value of dictionaries, you're tacitly claiming that anyone\n\nI don't consider opinions tangentially related to dictionary content a\nproof of anything.\n\nAlso it has been pointed out that dictionaries don't agree on the\nprecise definition - hence no final authority. The laguage use varies,\nand dictionaries also reflect that. Even the use of word 'impact'.\n\n> \n> >\n> > This will bring in reviews that focus on hairsplitting when the\n> > formulation with 'impact' reads better than 'effect' and where the\n> > change does not make it read any better so it should not be changed.\n> >\n> > It also brings in reviews of the sort that simply say that use of\n> > 'impact' is OK, and there is no need to change.\n> \n> That's an \"if\". This, however, is a situation where multiple people\n\nWe already received such reviews as response to your patch. It's not\nwhat-if.\n\nBest regards\n\nMichal\n"},{"id":"427233","messageId":"60c610f04b288_41f2b208ce@natae.notmuch","threadId":"55436","inReplyTo":"20210613114007.GF8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-13T14:06:40Z","receivedAt":"2021-06-13T14:06:46Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Sat, Jun 12, 2021 at 06:13:02PM -0500, Varun Varada wrote:\n> > On Thu, 27 May 2021 at 09:35, Michal Suchánek wrote:\n\n> > > That's only opinion, not evidence.\n> > \n> > Hence, the dictionary definitions, which are evidence. If people are\n> \n> The dictionaries provide definition, not usage guidelines.\n\nWhat do you think definitions are?\n\nA definition is there because many people use the word that way.\n\n> > Yes, there essentially is. It's called a dictionary. If you don't\n> > respect the value of dictionaries, you're tacitly claiming that anyone\n> \n> I don't consider opinions tangentially related to dictionary content a\n> proof of anything.\n> \n> Also it has been pointed out that dictionaries don't agree on the\n> precise definition - hence no final authority. The laguage use varies,\n> and dictionaries also reflect that. Even the use of word 'impact'.\n\nYou need to understand what dictionaries do: they describe current\nusage.\n\nIf some dictionaries say \"impact\" and \"affect\" are not 100% synonyms,\nthat means some people don't consider \"impact\" and \"affect\" to be\nsynonymns.\n\nPeriod.\n\n> > > This will bring in reviews that focus on hairsplitting when the\n> > > formulation with 'impact' reads better than 'effect' and where the\n> > > change does not make it read any better so it should not be changed.\n> > >\n> > > It also brings in reviews of the sort that simply say that use of\n> > > 'impact' is OK, and there is no need to change.\n> > \n> > That's an \"if\". This, however, is a situation where multiple people\n> \n> We already received such reviews as response to your patch. It's not\n> what-if.\n\nIn case you haven't been following this thread closely, you are the only\nperson that says the use of \"impact\" is OK. One person said \"impact\" was\nOK for him, but he didn't say anything of anybody else. Another person\nasked if they were synonyms. That's it.\n\nI say Varun should resend the patch separate from all other patches,\nexplain why they aren't synonyms and mention for the record that one\nperson objects to the change.\n\nIt's OK to merge patches where one person objects.\n\n-- \nFelipe Contreras"},{"id":"427240","messageId":"20210613162802.GG8544@kitsune.suse.cz","threadId":"55436","inReplyTo":"60c610f04b288_41f2b208ce@natae.notmuch","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2021-06-13T16:28:02Z","receivedAt":"2021-06-13T16:28:06Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Sun, Jun 13, 2021 at 09:06:40AM -0500, Felipe Contreras wrote:\n> Michal Suchánek wrote:\n> > On Sat, Jun 12, 2021 at 06:13:02PM -0500, Varun Varada wrote:\n\n> \n> > > > This will bring in reviews that focus on hairsplitting when the\n> > > > formulation with 'impact' reads better than 'effect' and where the\n> > > > change does not make it read any better so it should not be changed.\n> > > >\n> > > > It also brings in reviews of the sort that simply say that use of\n> > > > 'impact' is OK, and there is no need to change.\n> > > \n> > > That's an \"if\". This, however, is a situation where multiple people\n> > \n> > We already received such reviews as response to your patch. It's not\n> > what-if.\n> \n> In case you haven't been following this thread closely, you are the only\n> person that says the use of \"impact\" is OK. One person said \"impact\" was\n\nApparently you have not followed this thread closely yourself.\n\n> OK for him, but he didn't say anything of anybody else. Another person\n> asked if they were synonyms. That's it.\n> \n> I say Varun should resend the patch separate from all other patches,\n> explain why they aren't synonyms and mention for the record that one\n> person objects to the change.\n\nNo if he really wants the thing merged he should resend the patch with\nproper reasoning how replacing the word 'impact' improves the\ndocumentation and perhaps say for the record that two people find the\nword confusing.\n\n> \n> It's OK to merge patches where one person objects.\n\nApprantly you also missed that I am not opposed to the patch.\n\nBest regards\n\nMichal\n> \n> -- \n> Felipe Contreras\n"},{"id":"427243","messageId":"60c63c70c7cbe_41f4520874@natae.notmuch","threadId":"55436","inReplyTo":"20210613162802.GG8544@kitsune.suse.cz","subject":"Re: [PATCH] doc: replace jargon word \"impact\" with \"effect\"/\"affect\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-13T17:12:16Z","receivedAt":"2021-06-13T17:13:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Michal Suchánek wrote:\n> On Sun, Jun 13, 2021 at 09:06:40AM -0500, Felipe Contreras wrote:\n> > Michal Suchánek wrote:\n\n> > > We already received such reviews as response to your patch. It's not\n> > > what-if.\n> > \n> > In case you haven't been following this thread closely, you are the only\n> > person that says the use of \"impact\" is OK. One person said \"impact\" was\n> \n> Apparently you have not followed this thread closely yourself.\n\nI have. If you think you have, then list all the people that agree with\nyou that there's no problem with \"impact\" for the general population.\n\n> > It's OK to merge patches where one person objects.\n> \n> Apprantly you also missed that I am not opposed to the patch.\n\nGood. So some people are in favor of the patch, and nobody is against\nit.\n\n-- \nFelipe Contreras"}]}