* [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
@ 2021-04-05 21:48 Varun Varada
2021-04-06 9:24 ` Michal Suchánek
2021-05-13 10:40 ` Philip Oakley
0 siblings, 2 replies; 68+ messages in thread
From: Varun Varada @ 2021-04-05 21:48 UTC (permalink / raw)
To: git; +Cc: Varun Varada
There are a bunch of places in the code/docs which use the word "impact"
incorrectly. This is especially true of places where it says "will not
impact", which suggests that it might have an effect, albeit not as
strong of a one. This commit replaces all of these with their
appropriate alternative so that the docs not only does not use jargon,
but are also unambiguous.
Signed-off-by: Varun Varada <varuncvarada@gmail.com>
---
Documentation/MyFirstContribution.txt | 2 +-
Documentation/MyFirstObjectWalk.txt | 2 +-
Documentation/config/pack.txt | 2 +-
Documentation/git-fast-import.txt | 14 +++++++-------
Documentation/git-fetch.txt | 2 +-
.../technical/hash-function-transition.txt | 2 +-
Documentation/user-manual.txt | 4 ++--
advice.c | 2 +-
builtin/fast-import.c | 2 +-
builtin/pack-objects.c | 2 +-
compat/nedmalloc/malloc.c.h | 2 +-
contrib/coccinelle/README | 2 +-
dir.c | 2 +-
t/perf/p5550-fetch-tags.sh | 2 +-
t/t0008-ignores.sh | 2 +-
t/t0303-credential-external.sh | 2 +-
t/t2020-checkout-detach.sh | 4 ++--
t/t4013-diff-various.sh | 2 +-
t/t5000-tar-tree.sh | 2 +-
t/test-lib-functions.sh | 2 +-
20 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/Documentation/MyFirstContribution.txt
b/Documentation/MyFirstContribution.txt
index af0a9da62e..8372a7e59e 100644
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
how to show it in the general
command list shown by `git help git` or `git help -a`, which is generated from
`command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
line above it in alphabetical order. Now, we can add some attributes about the
-command which impacts where it shows up in the aforementioned help
commands. The
+command which affects where it shows up in the aforementioned help
commands. The
top of `command-list.txt` shares some information about what each attribute
means; in those help pages, the commands are sorted according to these
attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
diff --git a/Documentation/MyFirstObjectWalk.txt
b/Documentation/MyFirstObjectWalk.txt
index 2d10eea7a9..fd5bb8fb7d 100644
--- a/Documentation/MyFirstObjectWalk.txt
+++ b/Documentation/MyFirstObjectWalk.txt
@@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
By running your walk with and without the filter, you should find
that the total
object count in each case is identical. You can also time each invocation of
the `walken` subcommand, with and without `omitted` being passed in, to confirm
-to yourself the runtime impact of tracking all omitted objects.
+to yourself the runtime effect of tracking all omitted objects.
=== Changing the Order
diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
index 3da4ea98e2..00fcc9d7c7 100644
--- a/Documentation/config/pack.txt
+++ b/Documentation/config/pack.txt
@@ -55,7 +55,7 @@ pack.deltaCacheSize::
This cache is used to speed up the writing object phase by not
having to recompute the final delta result once the best match
for all objects is found. Repacking large repositories on machines
- which are tight with memory might be badly impacted by this though,
+ which are tight with memory might be badly affected by this though,
especially if this cache pushes the system into swapping.
A value of 0 means no limit. The smallest size of 1 byte may be
used to virtually disable this cache. Defaults to 256 MiB.
diff --git a/Documentation/git-fast-import.txt
b/Documentation/git-fast-import.txt
index 39cfa05b28..c6d8e4e1d7 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -58,7 +58,7 @@ OPTIONS
allowing fast-import to access the filesystem outside of the
repository). These options are disabled by default, but can be
allowed by providing this option on the command line. This
- currently impacts only the `export-marks`, `import-marks`, and
+ currently affects only the `export-marks`, `import-marks`, and
`import-marks-if-exists` feature commands.
+
Only enable this option if you trust the program generating the
@@ -687,7 +687,7 @@ that contains SP the path must be quoted.
A `filecopy` command takes effect immediately. Once the source
location has been copied to the destination any future commands
-applied to the source location will not impact the destination of
+applied to the source location will not affect the destination of
the copy.
`filerename`
@@ -708,7 +708,7 @@ that contains SP the path must be quoted.
A `filerename` command takes effect immediately. Once the source
location has been renamed to the destination any future commands
applied to the source location will create new files there and not
-impact the destination of the rename.
+affect the destination of the rename.
Note that a `filerename` is the same as a `filecopy` followed by a
`filedelete` of the source location. There is a slight performance
@@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
to be required).
~~~~~~~~~~
Causes fast-import to print the entire `progress` line unmodified to
its standard output channel (file descriptor 1) when the command is
-processed from the input stream. The command otherwise has no impact
+processed from the input stream. The command otherwise has no effect
on the current import, or on any of fast-import's internal state.
....
@@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
~~~~~~~~~~
Causes fast-import to print the SHA-1 corresponding to a mark to
stdout or to the file descriptor previously arranged with the
-`--cat-blob-fd` argument. The command otherwise has no impact on the
+`--cat-blob-fd` argument. The command otherwise has no effect on the
current import; its purpose is to retrieve SHA-1s that later commits
might want to refer to in their commit messages.
@@ -1050,7 +1050,7 @@ this output safely.
~~~~~~~~~~
Causes fast-import to print a blob to a file descriptor previously
arranged with the `--cat-blob-fd` argument. The command otherwise
-has no impact on the current import; its main purpose is to
+has no effect on the current import; its main purpose is to
retrieve blobs that may be in fast-import's memory but not
accessible from the target repository.
@@ -1366,7 +1366,7 @@ code considerably.
The branch LRU builtin to fast-import tends to behave very well, and the
cost of activating an inactive branch is so low that bouncing around
-between branches has virtually no impact on import performance.
+between branches has virtually no effect on import performance.
Handling Renames
~~~~~~~~~~~~~~~~
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 9067c2079e..01cf3b3d16 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
If left to accumulate, these stale references might make performance
worse on big and busy repos that have a lot of branch churn, and
e.g. make the output of commands like `git branch -a --contains
-<commit>` needlessly verbose, as well as impacting anything else
+<commit>` needlessly verbose, as well as affecting anything else
that'll work with the complete set of known references.
These remote-tracking references can be deleted as a one-off with
diff --git a/Documentation/technical/hash-function-transition.txt
b/Documentation/technical/hash-function-transition.txt
index 7c1630bf83..f4296faffc 100644
--- a/Documentation/technical/hash-function-transition.txt
+++ b/Documentation/technical/hash-function-transition.txt
@@ -42,7 +42,7 @@ mitigations.
If SHA-1 and its variants were to be truly broken, Git's hash function
could not be considered cryptographically secure any more. This would
-impact the communication of hash values because we could not trust
+affect the communication of hash values because we could not trust
that a given hash value represented the known good version of content
that the speaker intended.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index fd480b8645..33c60c49d7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
-state without impacting any branches by performing another switch.
+state without affecting any branches by performing another switch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command again. Example:
@@ -1189,7 +1189,7 @@ their histories forked. The work tree is
overwritten by the result of
the merge when this combining is done cleanly, or overwritten by a
half-merged results when this combining results in conflicts.
Therefore, if you have uncommitted changes touching the same files as
-the ones impacted by the merge, Git will refuse to proceed. Most of
+the ones affected by the merge, Git will refuse to proceed. Most of
the time, you will want to commit your changes before you can merge,
and if you don't, then linkgit:git-stash[1] can take these changes
away while you're doing the merge, and reapply them afterwards.
diff --git a/advice.c b/advice.c
index 164742305f..9cbbb824a9 100644
--- a/advice.c
+++ b/advice.c
@@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
"\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/builtin/fast-import.c b/builtin/fast-import.c
index 3afa81cf9a..24f362d2f4 100644
--- a/builtin/fast-import.c
+++ b/builtin/fast-import.c
@@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
const char *prefix)
* We don't parse most options until after we've seen the set of
* "feature" lines at the start of the stream (which allows the command
* line to override stream data). But we must do an early parse of any
- * command-line options that impact how we interpret the feature lines.
+ * command-line options that affect how we interpret the feature lines.
*/
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 525c2d8552..749bbca241 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
/*
* Mark ourselves as active and see if the next step causes
* us to cycle to another active object. It's important to do
- * this _before_ we loop, because it impacts where we make the
+ * this _before_ we loop, because it affects where we make the
* cut, and thus how our total_depth counter works.
* E.g., We may see a partial loop like:
*
diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h
index 814845d4b3..de13121d76 100644
--- a/compat/nedmalloc/malloc.c.h
+++ b/compat/nedmalloc/malloc.c.h
@@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
#endif /* (FOOTERS && !INSECURE) */
-/* In gcc, use __builtin_expect to minimize impact of checks */
+/* In gcc, use __builtin_expect to minimize affect of checks */
#if !INSECURE
#if defined(__GNUC__) && __GNUC__ >= 3
#define RTCHECK(e) __builtin_expect(e, 1)
diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
index f0e80bd7f0..92979ec770 100644
--- a/contrib/coccinelle/README
+++ b/contrib/coccinelle/README
@@ -40,4 +40,4 @@ There are two types of semantic patches:
are ignored for checks, and can be applied using 'make coccicheck-pending'.
This allows to expose plans of pending large scale refactorings without
- impacting the bad pattern checks.
+ affecting the bad pattern checks.
diff --git a/dir.c b/dir.c
index 3474e67e8f..235e26a90e 100644
--- a/dir.c
+++ b/dir.c
@@ -2144,7 +2144,7 @@ static enum path_treatment
treat_path_fast(struct dir_struct *dir,
/*
* We get path_recurse in the first run when
* directory_exists_in_index() returns index_nonexistent. We
- * are sure that new changes in the index does not impact the
+ * are sure that new changes in the index does not affect the
* outcome. Return now.
*/
return path_recurse;
diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
index d0e0e019ea..1fcb98443c 100755
--- a/t/perf/p5550-fetch-tags.sh
+++ b/t/perf/p5550-fetch-tags.sh
@@ -8,7 +8,7 @@ follows.
The parent repository has a large number of tags which are disconnected from
the rest of history. That makes them candidates for tag-following, but we never
-actually grab them (and thus they will impact each subsequent fetch).
+actually grab them (and thus they will affect each subsequent fetch).
The child repository is a clone of parent, without the tags, and is at least
one commit behind the parent (meaning that we will fetch one object and then
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index a594b4aa7d..95daba4000 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
# test standard ignores
# First make sure that the presence of a file in the working tree
-# does not impact results, but that the presence of a file in the
+# does not affect results, but that the presence of a file in the
# index does unless the --no-index option is used.
for subdir in '' 'a/'
diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
index f028fd1418..a9348f655a 100755
--- a/t/t0303-credential-external.sh
+++ b/t/t0303-credential-external.sh
@@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
# clean before the test in case there is cruft left
-# over from a previous run that would impact results
+# over from a previous run that would affect results
helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
helper_test "$GIT_TEST_CREDENTIAL_HELPER"
diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
index bc46713a43..568c258c5a 100755
--- a/t/t2020-checkout-detach.sh
+++ b/t/t2020-checkout-detach.sh
@@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
no SHA-1 ellipsis when not as
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
- state without impacting any branches by switching back to a branch.
+ state without affecting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
@@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
print SHA-1 ellipsis when asked
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
- state without impacting any branches by switching back to a branch.
+ state without affecting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 6cca8b84a6..97365a7786 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -109,7 +109,7 @@ test_expect_success setup '
git checkout -f master &&
# Same merge as master, but with parents reversed. Hide it in a
- # pseudo-ref to avoid impacting tests with --all.
+ # pseudo-ref to avoid affecting tests with --all.
commit=$(echo reverse |
git commit-tree -p master^2 -p master^1 master^{tree}) &&
git update-ref REVERSE $commit &&
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 7204799a0b..33a6efce2f 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
# Pull the size and date of each entry in a tarfile using the system tar.
#
# We'll pull out only the year from the date; that avoids any question of
-# timezones impacting the result (as long as we keep our test times away from a
+# timezones affecting the result (as long as we keep our test times away from a
# year boundary; our reference times are all in August).
#
# The output of tar_info is expected to be "<size> <year>", both in decimal. It
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 6348e8d733..ff65f86f50 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
}
# Like "env FOO=BAR some-program", but run inside a subshell, which means
-# it also works for shell functions (though those functions cannot impact
+# it also works for shell functions (though those functions cannot affect
# the environment outside of the test_env invocation).
test_env () {
(
--
2.17.1
From varun Mon Apr 5 16:45:37 2021
Return-Path: <varun>
Received: (from varun@localhost)
by black-diamond (8.15.2/8.15.2/Submit) id 135LjbIS027022;
Mon, 5 Apr 2021 16:45:37 -0500
From: Varun Varada <varuncvarada@gmail.com>
To: git@vger.kernel.org
Cc: Varun Varada <varuncvarada@gmail.com>
Subject: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
Date: Mon, 5 Apr 2021 16:44:35 -0500
Message-Id: <20210405214435.26979-1-varuncvarada@gmail.com>
X-Mailer: git-send-email 2.17.1
There are a bunch of places in the code/docs which use the word "impact"
incorrectly. This is especially true of places where it says "will not
impact", which suggests that it might have an effect, albeit not as
strong of a one. This commit replaces all of these with their
appropriate alternative so that the docs not only does not use jargon,
but are also unambiguous.
Signed-off-by: Varun Varada <varuncvarada@gmail.com>
---
Documentation/MyFirstContribution.txt | 2 +-
Documentation/MyFirstObjectWalk.txt | 2 +-
Documentation/config/pack.txt | 2 +-
Documentation/git-fast-import.txt | 14 +++++++-------
Documentation/git-fetch.txt | 2 +-
.../technical/hash-function-transition.txt | 2 +-
Documentation/user-manual.txt | 4 ++--
advice.c | 2 +-
builtin/fast-import.c | 2 +-
builtin/pack-objects.c | 2 +-
compat/nedmalloc/malloc.c.h | 2 +-
contrib/coccinelle/README | 2 +-
dir.c | 2 +-
t/perf/p5550-fetch-tags.sh | 2 +-
t/t0008-ignores.sh | 2 +-
t/t0303-credential-external.sh | 2 +-
t/t2020-checkout-detach.sh | 4 ++--
t/t4013-diff-various.sh | 2 +-
t/t5000-tar-tree.sh | 2 +-
t/test-lib-functions.sh | 2 +-
20 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/Documentation/MyFirstContribution.txt
b/Documentation/MyFirstContribution.txt
index af0a9da62e..8372a7e59e 100644
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
how to show it in the general
command list shown by `git help git` or `git help -a`, which is generated from
`command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
line above it in alphabetical order. Now, we can add some attributes about the
-command which impacts where it shows up in the aforementioned help
commands. The
+command which affects where it shows up in the aforementioned help
commands. The
top of `command-list.txt` shares some information about what each attribute
means; in those help pages, the commands are sorted according to these
attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
diff --git a/Documentation/MyFirstObjectWalk.txt
b/Documentation/MyFirstObjectWalk.txt
index 2d10eea7a9..fd5bb8fb7d 100644
--- a/Documentation/MyFirstObjectWalk.txt
+++ b/Documentation/MyFirstObjectWalk.txt
@@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
By running your walk with and without the filter, you should find
that the total
object count in each case is identical. You can also time each invocation of
the `walken` subcommand, with and without `omitted` being passed in, to confirm
-to yourself the runtime impact of tracking all omitted objects.
+to yourself the runtime effect of tracking all omitted objects.
=== Changing the Order
diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
index 3da4ea98e2..00fcc9d7c7 100644
--- a/Documentation/config/pack.txt
+++ b/Documentation/config/pack.txt
@@ -55,7 +55,7 @@ pack.deltaCacheSize::
This cache is used to speed up the writing object phase by not
having to recompute the final delta result once the best match
for all objects is found. Repacking large repositories on machines
- which are tight with memory might be badly impacted by this though,
+ which are tight with memory might be badly affected by this though,
especially if this cache pushes the system into swapping.
A value of 0 means no limit. The smallest size of 1 byte may be
used to virtually disable this cache. Defaults to 256 MiB.
diff --git a/Documentation/git-fast-import.txt
b/Documentation/git-fast-import.txt
index 39cfa05b28..c6d8e4e1d7 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -58,7 +58,7 @@ OPTIONS
allowing fast-import to access the filesystem outside of the
repository). These options are disabled by default, but can be
allowed by providing this option on the command line. This
- currently impacts only the `export-marks`, `import-marks`, and
+ currently affects only the `export-marks`, `import-marks`, and
`import-marks-if-exists` feature commands.
+
Only enable this option if you trust the program generating the
@@ -687,7 +687,7 @@ that contains SP the path must be quoted.
A `filecopy` command takes effect immediately. Once the source
location has been copied to the destination any future commands
-applied to the source location will not impact the destination of
+applied to the source location will not affect the destination of
the copy.
`filerename`
@@ -708,7 +708,7 @@ that contains SP the path must be quoted.
A `filerename` command takes effect immediately. Once the source
location has been renamed to the destination any future commands
applied to the source location will create new files there and not
-impact the destination of the rename.
+affect the destination of the rename.
Note that a `filerename` is the same as a `filecopy` followed by a
`filedelete` of the source location. There is a slight performance
@@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
to be required).
~~~~~~~~~~
Causes fast-import to print the entire `progress` line unmodified to
its standard output channel (file descriptor 1) when the command is
-processed from the input stream. The command otherwise has no impact
+processed from the input stream. The command otherwise has no effect
on the current import, or on any of fast-import's internal state.
....
@@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
~~~~~~~~~~
Causes fast-import to print the SHA-1 corresponding to a mark to
stdout or to the file descriptor previously arranged with the
-`--cat-blob-fd` argument. The command otherwise has no impact on the
+`--cat-blob-fd` argument. The command otherwise has no effect on the
current import; its purpose is to retrieve SHA-1s that later commits
might want to refer to in their commit messages.
@@ -1050,7 +1050,7 @@ this output safely.
~~~~~~~~~~
Causes fast-import to print a blob to a file descriptor previously
arranged with the `--cat-blob-fd` argument. The command otherwise
-has no impact on the current import; its main purpose is to
+has no effect on the current import; its main purpose is to
retrieve blobs that may be in fast-import's memory but not
accessible from the target repository.
@@ -1366,7 +1366,7 @@ code considerably.
The branch LRU builtin to fast-import tends to behave very well, and the
cost of activating an inactive branch is so low that bouncing around
-between branches has virtually no impact on import performance.
+between branches has virtually no effect on import performance.
Handling Renames
~~~~~~~~~~~~~~~~
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 9067c2079e..01cf3b3d16 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
If left to accumulate, these stale references might make performance
worse on big and busy repos that have a lot of branch churn, and
e.g. make the output of commands like `git branch -a --contains
-<commit>` needlessly verbose, as well as impacting anything else
+<commit>` needlessly verbose, as well as affecting anything else
that'll work with the complete set of known references.
These remote-tracking references can be deleted as a one-off with
diff --git a/Documentation/technical/hash-function-transition.txt
b/Documentation/technical/hash-function-transition.txt
index 7c1630bf83..f4296faffc 100644
--- a/Documentation/technical/hash-function-transition.txt
+++ b/Documentation/technical/hash-function-transition.txt
@@ -42,7 +42,7 @@ mitigations.
If SHA-1 and its variants were to be truly broken, Git's hash function
could not be considered cryptographically secure any more. This would
-impact the communication of hash values because we could not trust
+affect the communication of hash values because we could not trust
that a given hash value represented the known good version of content
that the speaker intended.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index fd480b8645..33c60c49d7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
-state without impacting any branches by performing another switch.
+state without affecting any branches by performing another switch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command again. Example:
@@ -1189,7 +1189,7 @@ their histories forked. The work tree is
overwritten by the result of
the merge when this combining is done cleanly, or overwritten by a
half-merged results when this combining results in conflicts.
Therefore, if you have uncommitted changes touching the same files as
-the ones impacted by the merge, Git will refuse to proceed. Most of
+the ones affected by the merge, Git will refuse to proceed. Most of
the time, you will want to commit your changes before you can merge,
and if you don't, then linkgit:git-stash[1] can take these changes
away while you're doing the merge, and reapply them afterwards.
diff --git a/advice.c b/advice.c
index 164742305f..9cbbb824a9 100644
--- a/advice.c
+++ b/advice.c
@@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
"\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/builtin/fast-import.c b/builtin/fast-import.c
index 3afa81cf9a..24f362d2f4 100644
--- a/builtin/fast-import.c
+++ b/builtin/fast-import.c
@@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
const char *prefix)
* We don't parse most options until after we've seen the set of
* "feature" lines at the start of the stream (which allows the command
* line to override stream data). But we must do an early parse of any
- * command-line options that impact how we interpret the feature lines.
+ * command-line options that affect how we interpret the feature lines.
*/
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 525c2d8552..749bbca241 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
/*
* Mark ourselves as active and see if the next step causes
* us to cycle to another active object. It's important to do
- * this _before_ we loop, because it impacts where we make the
+ * this _before_ we loop, because it affects where we make the
* cut, and thus how our total_depth counter works.
* E.g., We may see a partial loop like:
*
diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h
index 814845d4b3..de13121d76 100644
--- a/compat/nedmalloc/malloc.c.h
+++ b/compat/nedmalloc/malloc.c.h
@@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
#endif /* (FOOTERS && !INSECURE) */
-/* In gcc, use __builtin_expect to minimize impact of checks */
+/* In gcc, use __builtin_expect to minimize affect of checks */
#if !INSECURE
#if defined(__GNUC__) && __GNUC__ >= 3
#define RTCHECK(e) __builtin_expect(e, 1)
diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
index f0e80bd7f0..92979ec770 100644
--- a/contrib/coccinelle/README
+++ b/contrib/coccinelle/README
@@ -40,4 +40,4 @@ There are two types of semantic patches:
are ignored for checks, and can be applied using 'make coccicheck-pending'.
This allows to expose plans of pending large scale refactorings without
- impacting the bad pattern checks.
+ affecting the bad pattern checks.
diff --git a/dir.c b/dir.c
index 3474e67e8f..235e26a90e 100644
--- a/dir.c
+++ b/dir.c
@@ -2144,7 +2144,7 @@ static enum path_treatment
treat_path_fast(struct dir_struct *dir,
/*
* We get path_recurse in the first run when
* directory_exists_in_index() returns index_nonexistent. We
- * are sure that new changes in the index does not impact the
+ * are sure that new changes in the index does not affect the
* outcome. Return now.
*/
return path_recurse;
diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
index d0e0e019ea..1fcb98443c 100755
--- a/t/perf/p5550-fetch-tags.sh
+++ b/t/perf/p5550-fetch-tags.sh
@@ -8,7 +8,7 @@ follows.
The parent repository has a large number of tags which are disconnected from
the rest of history. That makes them candidates for tag-following, but we never
-actually grab them (and thus they will impact each subsequent fetch).
+actually grab them (and thus they will affect each subsequent fetch).
The child repository is a clone of parent, without the tags, and is at least
one commit behind the parent (meaning that we will fetch one object and then
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index a594b4aa7d..95daba4000 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
# test standard ignores
# First make sure that the presence of a file in the working tree
-# does not impact results, but that the presence of a file in the
+# does not affect results, but that the presence of a file in the
# index does unless the --no-index option is used.
for subdir in '' 'a/'
diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
index f028fd1418..a9348f655a 100755
--- a/t/t0303-credential-external.sh
+++ b/t/t0303-credential-external.sh
@@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
# clean before the test in case there is cruft left
-# over from a previous run that would impact results
+# over from a previous run that would affect results
helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
helper_test "$GIT_TEST_CREDENTIAL_HELPER"
diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
index bc46713a43..568c258c5a 100755
--- a/t/t2020-checkout-detach.sh
+++ b/t/t2020-checkout-detach.sh
@@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
no SHA-1 ellipsis when not as
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
- state without impacting any branches by switching back to a branch.
+ state without affecting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
@@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
print SHA-1 ellipsis when asked
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
- state without impacting any branches by switching back to a branch.
+ state without affecting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 6cca8b84a6..97365a7786 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -109,7 +109,7 @@ test_expect_success setup '
git checkout -f master &&
# Same merge as master, but with parents reversed. Hide it in a
- # pseudo-ref to avoid impacting tests with --all.
+ # pseudo-ref to avoid affecting tests with --all.
commit=$(echo reverse |
git commit-tree -p master^2 -p master^1 master^{tree}) &&
git update-ref REVERSE $commit &&
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 7204799a0b..33a6efce2f 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
# Pull the size and date of each entry in a tarfile using the system tar.
#
# We'll pull out only the year from the date; that avoids any question of
-# timezones impacting the result (as long as we keep our test times away from a
+# timezones affecting the result (as long as we keep our test times away from a
# year boundary; our reference times are all in August).
#
# The output of tar_info is expected to be "<size> <year>", both in decimal. It
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 6348e8d733..ff65f86f50 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
}
# Like "env FOO=BAR some-program", but run inside a subshell, which means
-# it also works for shell functions (though those functions cannot impact
+# it also works for shell functions (though those functions cannot affect
# the environment outside of the test_env invocation).
test_env () {
(
--
2.17.1
^ permalink raw reply related [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-05 21:48 [PATCH] doc: replace jargon word "impact" with "effect"/"affect" Varun Varada
@ 2021-04-06 9:24 ` Michal Suchánek
2021-04-06 19:36 ` Varun Varada
2021-05-11 19:21 ` Felipe Contreras
2021-05-13 10:40 ` Philip Oakley
1 sibling, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-04-06 9:24 UTC (permalink / raw)
To: Varun Varada; +Cc: git
On Mon, Apr 05, 2021 at 04:48:58PM -0500, Varun Varada wrote:
> There are a bunch of places in the code/docs which use the word "impact"
> incorrectly. This is especially true of places where it says "will not
> impact", which suggests that it might have an effect, albeit not as
> strong of a one. This commit replaces all of these with their
> appropriate alternative so that the docs not only does not use jargon,
> but are also unambiguous.
Hello,
while using "will not impact" in an incorrect or unclear way may be a
problem the word "impact" in itself is not "jargon".
From The Collaborative International Dictionary of English v.0.48 :
Impact \Im*pact"\, v. t. [imp. & p. p. Impacted; p. pr. & vb.
n. Impacting.] [L. impactus, p. p. of impingere to push,
strike against. See Impinge.]
1. To drive close; to press firmly together: to wedge into a
place. --Woodward.
[1913 Webster]
2. To affect or influence, especially in a significant or
undesirable manner; as, budget cuts impacted the entire
research program; the fish populations were adversely
impacted by pollution.
[PJC]
3. To collide forcefully with; to strike.
[PJC]
From WordNet (r) 3.0 (2006) :
impact
n 1: the striking of one body against another
2: a forceful consequence; a strong effect; "the book had an
important impact on my thinking"; "the book packs a wallop"
[syn: impact, wallop]
3: influencing strongly; "they resented the impingement of
American values on European culture" [syn: impingement,
encroachment, impact]
4: the violent interaction of individuals or groups entering
into combat; "the armies met in the shock of battle" [syn:
shock, impact]
v 1: press or wedge together; pack together
2: have an effect upon; "Will the new rules affect me?" [syn:
affect, impact, bear upon, bear on, touch on,
touch]
From Merriam-Webster dictionary:
impact
noun
im·pact | \ ˈim-ˌpakt How to pronounce impact (audio) \
plural impacts
1a : an impinging or striking especially of one body against another
b : a forceful contact or onset also : the impetus communicated in or as
if in such a contact
2 : the force of impression of one thing on another : a significant or
major effect the impact of science on our society a study outlining the
potential environmental impacts of the construction project
impact
verb
im·pact | \ im-ˈpakt How to pronounce impact (audio) \
impacted; impacting; impacts
transitive verb
1a : to have a direct effect or impact on : impinge on
b : to strike forcefully also : to cause to strike forcefully
2a : to fix firmly by or as if by packing or wedging
b : to press together
intransitive verb
1 : to have an impact —often used with on
2 : to impinge or make contact especially forcefully
If you are concerned about correctness and clarity of the documentation please
avoid spreading misinformation.
Thanks
Michal
> Signed-off-by: Varun Varada <varuncvarada@gmail.com>
> ---
> Documentation/MyFirstContribution.txt | 2 +-
> Documentation/MyFirstObjectWalk.txt | 2 +-
> Documentation/config/pack.txt | 2 +-
> Documentation/git-fast-import.txt | 14 +++++++-------
> Documentation/git-fetch.txt | 2 +-
> .../technical/hash-function-transition.txt | 2 +-
> Documentation/user-manual.txt | 4 ++--
> advice.c | 2 +-
> builtin/fast-import.c | 2 +-
> builtin/pack-objects.c | 2 +-
> compat/nedmalloc/malloc.c.h | 2 +-
> contrib/coccinelle/README | 2 +-
> dir.c | 2 +-
> t/perf/p5550-fetch-tags.sh | 2 +-
> t/t0008-ignores.sh | 2 +-
> t/t0303-credential-external.sh | 2 +-
> t/t2020-checkout-detach.sh | 4 ++--
> t/t4013-diff-various.sh | 2 +-
> t/t5000-tar-tree.sh | 2 +-
> t/test-lib-functions.sh | 2 +-
> 20 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/Documentation/MyFirstContribution.txt
> b/Documentation/MyFirstContribution.txt
> index af0a9da62e..8372a7e59e 100644
> --- a/Documentation/MyFirstContribution.txt
> +++ b/Documentation/MyFirstContribution.txt
> @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> how to show it in the general
> command list shown by `git help git` or `git help -a`, which is generated from
> `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> line above it in alphabetical order. Now, we can add some attributes about the
> -command which impacts where it shows up in the aforementioned help
> commands. The
> +command which affects where it shows up in the aforementioned help
> commands. The
> top of `command-list.txt` shares some information about what each attribute
> means; in those help pages, the commands are sorted according to these
> attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> diff --git a/Documentation/MyFirstObjectWalk.txt
> b/Documentation/MyFirstObjectWalk.txt
> index 2d10eea7a9..fd5bb8fb7d 100644
> --- a/Documentation/MyFirstObjectWalk.txt
> +++ b/Documentation/MyFirstObjectWalk.txt
> @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> By running your walk with and without the filter, you should find
> that the total
> object count in each case is identical. You can also time each invocation of
> the `walken` subcommand, with and without `omitted` being passed in, to confirm
> -to yourself the runtime impact of tracking all omitted objects.
> +to yourself the runtime effect of tracking all omitted objects.
>
> === Changing the Order
>
> diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> index 3da4ea98e2..00fcc9d7c7 100644
> --- a/Documentation/config/pack.txt
> +++ b/Documentation/config/pack.txt
> @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> This cache is used to speed up the writing object phase by not
> having to recompute the final delta result once the best match
> for all objects is found. Repacking large repositories on machines
> - which are tight with memory might be badly impacted by this though,
> + which are tight with memory might be badly affected by this though,
> especially if this cache pushes the system into swapping.
> A value of 0 means no limit. The smallest size of 1 byte may be
> used to virtually disable this cache. Defaults to 256 MiB.
> diff --git a/Documentation/git-fast-import.txt
> b/Documentation/git-fast-import.txt
> index 39cfa05b28..c6d8e4e1d7 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -58,7 +58,7 @@ OPTIONS
> allowing fast-import to access the filesystem outside of the
> repository). These options are disabled by default, but can be
> allowed by providing this option on the command line. This
> - currently impacts only the `export-marks`, `import-marks`, and
> + currently affects only the `export-marks`, `import-marks`, and
> `import-marks-if-exists` feature commands.
> +
> Only enable this option if you trust the program generating the
> @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
>
> A `filecopy` command takes effect immediately. Once the source
> location has been copied to the destination any future commands
> -applied to the source location will not impact the destination of
> +applied to the source location will not affect the destination of
> the copy.
>
> `filerename`
> @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> A `filerename` command takes effect immediately. Once the source
> location has been renamed to the destination any future commands
> applied to the source location will create new files there and not
> -impact the destination of the rename.
> +affect the destination of the rename.
>
> Note that a `filerename` is the same as a `filecopy` followed by a
> `filedelete` of the source location. There is a slight performance
> @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> to be required).
> ~~~~~~~~~~
> Causes fast-import to print the entire `progress` line unmodified to
> its standard output channel (file descriptor 1) when the command is
> -processed from the input stream. The command otherwise has no impact
> +processed from the input stream. The command otherwise has no effect
> on the current import, or on any of fast-import's internal state.
>
> ....
> @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> ~~~~~~~~~~
> Causes fast-import to print the SHA-1 corresponding to a mark to
> stdout or to the file descriptor previously arranged with the
> -`--cat-blob-fd` argument. The command otherwise has no impact on the
> +`--cat-blob-fd` argument. The command otherwise has no effect on the
> current import; its purpose is to retrieve SHA-1s that later commits
> might want to refer to in their commit messages.
>
> @@ -1050,7 +1050,7 @@ this output safely.
> ~~~~~~~~~~
> Causes fast-import to print a blob to a file descriptor previously
> arranged with the `--cat-blob-fd` argument. The command otherwise
> -has no impact on the current import; its main purpose is to
> +has no effect on the current import; its main purpose is to
> retrieve blobs that may be in fast-import's memory but not
> accessible from the target repository.
>
> @@ -1366,7 +1366,7 @@ code considerably.
>
> The branch LRU builtin to fast-import tends to behave very well, and the
> cost of activating an inactive branch is so low that bouncing around
> -between branches has virtually no impact on import performance.
> +between branches has virtually no effect on import performance.
>
> Handling Renames
> ~~~~~~~~~~~~~~~~
> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> index 9067c2079e..01cf3b3d16 100644
> --- a/Documentation/git-fetch.txt
> +++ b/Documentation/git-fetch.txt
> @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> If left to accumulate, these stale references might make performance
> worse on big and busy repos that have a lot of branch churn, and
> e.g. make the output of commands like `git branch -a --contains
> -<commit>` needlessly verbose, as well as impacting anything else
> +<commit>` needlessly verbose, as well as affecting anything else
> that'll work with the complete set of known references.
>
> These remote-tracking references can be deleted as a one-off with
> diff --git a/Documentation/technical/hash-function-transition.txt
> b/Documentation/technical/hash-function-transition.txt
> index 7c1630bf83..f4296faffc 100644
> --- a/Documentation/technical/hash-function-transition.txt
> +++ b/Documentation/technical/hash-function-transition.txt
> @@ -42,7 +42,7 @@ mitigations.
>
> If SHA-1 and its variants were to be truly broken, Git's hash function
> could not be considered cryptographically secure any more. This would
> -impact the communication of hash values because we could not trust
> +affect the communication of hash values because we could not trust
> that a given hash value represented the known good version of content
> that the speaker intended.
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index fd480b8645..33c60c49d7 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> -state without impacting any branches by performing another switch.
> +state without affecting any branches by performing another switch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command again. Example:
> @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> overwritten by the result of
> the merge when this combining is done cleanly, or overwritten by a
> half-merged results when this combining results in conflicts.
> Therefore, if you have uncommitted changes touching the same files as
> -the ones impacted by the merge, Git will refuse to proceed. Most of
> +the ones affected by the merge, Git will refuse to proceed. Most of
> the time, you will want to commit your changes before you can merge,
> and if you don't, then linkgit:git-stash[1] can take these changes
> away while you're doing the merge, and reapply them afterwards.
> diff --git a/advice.c b/advice.c
> index 164742305f..9cbbb824a9 100644
> --- a/advice.c
> +++ b/advice.c
> @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> "\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/builtin/fast-import.c b/builtin/fast-import.c
> index 3afa81cf9a..24f362d2f4 100644
> --- a/builtin/fast-import.c
> +++ b/builtin/fast-import.c
> @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> const char *prefix)
> * We don't parse most options until after we've seen the set of
> * "feature" lines at the start of the stream (which allows the command
> * line to override stream data). But we must do an early parse of any
> - * command-line options that impact how we interpret the feature lines.
> + * command-line options that affect how we interpret the feature lines.
> */
> for (i = 1; i < argc; i++) {
> const char *arg = argv[i];
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index 525c2d8552..749bbca241 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> /*
> * Mark ourselves as active and see if the next step causes
> * us to cycle to another active object. It's important to do
> - * this _before_ we loop, because it impacts where we make the
> + * this _before_ we loop, because it affects where we make the
> * cut, and thus how our total_depth counter works.
> * E.g., We may see a partial loop like:
> *
> diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h
> index 814845d4b3..de13121d76 100644
> --- a/compat/nedmalloc/malloc.c.h
> +++ b/compat/nedmalloc/malloc.c.h
> @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> #endif /* (FOOTERS && !INSECURE) */
>
>
> -/* In gcc, use __builtin_expect to minimize impact of checks */
> +/* In gcc, use __builtin_expect to minimize affect of checks */
> #if !INSECURE
> #if defined(__GNUC__) && __GNUC__ >= 3
> #define RTCHECK(e) __builtin_expect(e, 1)
> diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> index f0e80bd7f0..92979ec770 100644
> --- a/contrib/coccinelle/README
> +++ b/contrib/coccinelle/README
> @@ -40,4 +40,4 @@ There are two types of semantic patches:
> are ignored for checks, and can be applied using 'make coccicheck-pending'.
>
> This allows to expose plans of pending large scale refactorings without
> - impacting the bad pattern checks.
> + affecting the bad pattern checks.
> diff --git a/dir.c b/dir.c
> index 3474e67e8f..235e26a90e 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -2144,7 +2144,7 @@ static enum path_treatment
> treat_path_fast(struct dir_struct *dir,
> /*
> * We get path_recurse in the first run when
> * directory_exists_in_index() returns index_nonexistent. We
> - * are sure that new changes in the index does not impact the
> + * are sure that new changes in the index does not affect the
> * outcome. Return now.
> */
> return path_recurse;
> diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> index d0e0e019ea..1fcb98443c 100755
> --- a/t/perf/p5550-fetch-tags.sh
> +++ b/t/perf/p5550-fetch-tags.sh
> @@ -8,7 +8,7 @@ follows.
>
> The parent repository has a large number of tags which are disconnected from
> the rest of history. That makes them candidates for tag-following, but we never
> -actually grab them (and thus they will impact each subsequent fetch).
> +actually grab them (and thus they will affect each subsequent fetch).
>
> The child repository is a clone of parent, without the tags, and is at least
> one commit behind the parent (meaning that we will fetch one object and then
> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> index a594b4aa7d..95daba4000 100755
> --- a/t/t0008-ignores.sh
> +++ b/t/t0008-ignores.sh
> @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> # test standard ignores
>
> # First make sure that the presence of a file in the working tree
> -# does not impact results, but that the presence of a file in the
> +# does not affect results, but that the presence of a file in the
> # index does unless the --no-index option is used.
>
> for subdir in '' 'a/'
> diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> index f028fd1418..a9348f655a 100755
> --- a/t/t0303-credential-external.sh
> +++ b/t/t0303-credential-external.sh
> @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
>
> # clean before the test in case there is cruft left
> -# over from a previous run that would impact results
> +# over from a previous run that would affect results
> helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
>
> helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> index bc46713a43..568c258c5a 100755
> --- a/t/t2020-checkout-detach.sh
> +++ b/t/t2020-checkout-detach.sh
> @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> no SHA-1 ellipsis when not as
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> - state without impacting any branches by switching back to a branch.
> + state without affecting any branches by switching back to a branch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command. Example:
> @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> print SHA-1 ellipsis when asked
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> - state without impacting any branches by switching back to a branch.
> + state without affecting any branches by switching back to a branch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command. Example:
> diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> index 6cca8b84a6..97365a7786 100755
> --- a/t/t4013-diff-various.sh
> +++ b/t/t4013-diff-various.sh
> @@ -109,7 +109,7 @@ test_expect_success setup '
> git checkout -f master &&
>
> # Same merge as master, but with parents reversed. Hide it in a
> - # pseudo-ref to avoid impacting tests with --all.
> + # pseudo-ref to avoid affecting tests with --all.
> commit=$(echo reverse |
> git commit-tree -p master^2 -p master^1 master^{tree}) &&
> git update-ref REVERSE $commit &&
> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> index 7204799a0b..33a6efce2f 100755
> --- a/t/t5000-tar-tree.sh
> +++ b/t/t5000-tar-tree.sh
> @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> # Pull the size and date of each entry in a tarfile using the system tar.
> #
> # We'll pull out only the year from the date; that avoids any question of
> -# timezones impacting the result (as long as we keep our test times away from a
> +# timezones affecting the result (as long as we keep our test times away from a
> # year boundary; our reference times are all in August).
> #
> # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index 6348e8d733..ff65f86f50 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> }
>
> # Like "env FOO=BAR some-program", but run inside a subshell, which means
> -# it also works for shell functions (though those functions cannot impact
> +# it also works for shell functions (though those functions cannot affect
> # the environment outside of the test_env invocation).
> test_env () {
> (
> --
> 2.17.1
>
>
> From varun Mon Apr 5 16:45:37 2021
> Return-Path: <varun>
> Received: (from varun@localhost)
> by black-diamond (8.15.2/8.15.2/Submit) id 135LjbIS027022;
> Mon, 5 Apr 2021 16:45:37 -0500
> From: Varun Varada <varuncvarada@gmail.com>
> To: git@vger.kernel.org
> Cc: Varun Varada <varuncvarada@gmail.com>
> Subject: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
> Date: Mon, 5 Apr 2021 16:44:35 -0500
> Message-Id: <20210405214435.26979-1-varuncvarada@gmail.com>
> X-Mailer: git-send-email 2.17.1
>
> There are a bunch of places in the code/docs which use the word "impact"
> incorrectly. This is especially true of places where it says "will not
> impact", which suggests that it might have an effect, albeit not as
> strong of a one. This commit replaces all of these with their
> appropriate alternative so that the docs not only does not use jargon,
> but are also unambiguous.
>
> Signed-off-by: Varun Varada <varuncvarada@gmail.com>
> ---
> Documentation/MyFirstContribution.txt | 2 +-
> Documentation/MyFirstObjectWalk.txt | 2 +-
> Documentation/config/pack.txt | 2 +-
> Documentation/git-fast-import.txt | 14 +++++++-------
> Documentation/git-fetch.txt | 2 +-
> .../technical/hash-function-transition.txt | 2 +-
> Documentation/user-manual.txt | 4 ++--
> advice.c | 2 +-
> builtin/fast-import.c | 2 +-
> builtin/pack-objects.c | 2 +-
> compat/nedmalloc/malloc.c.h | 2 +-
> contrib/coccinelle/README | 2 +-
> dir.c | 2 +-
> t/perf/p5550-fetch-tags.sh | 2 +-
> t/t0008-ignores.sh | 2 +-
> t/t0303-credential-external.sh | 2 +-
> t/t2020-checkout-detach.sh | 4 ++--
> t/t4013-diff-various.sh | 2 +-
> t/t5000-tar-tree.sh | 2 +-
> t/test-lib-functions.sh | 2 +-
> 20 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/Documentation/MyFirstContribution.txt
> b/Documentation/MyFirstContribution.txt
> index af0a9da62e..8372a7e59e 100644
> --- a/Documentation/MyFirstContribution.txt
> +++ b/Documentation/MyFirstContribution.txt
> @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> how to show it in the general
> command list shown by `git help git` or `git help -a`, which is generated from
> `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> line above it in alphabetical order. Now, we can add some attributes about the
> -command which impacts where it shows up in the aforementioned help
> commands. The
> +command which affects where it shows up in the aforementioned help
> commands. The
> top of `command-list.txt` shares some information about what each attribute
> means; in those help pages, the commands are sorted according to these
> attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> diff --git a/Documentation/MyFirstObjectWalk.txt
> b/Documentation/MyFirstObjectWalk.txt
> index 2d10eea7a9..fd5bb8fb7d 100644
> --- a/Documentation/MyFirstObjectWalk.txt
> +++ b/Documentation/MyFirstObjectWalk.txt
> @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> By running your walk with and without the filter, you should find
> that the total
> object count in each case is identical. You can also time each invocation of
> the `walken` subcommand, with and without `omitted` being passed in, to confirm
> -to yourself the runtime impact of tracking all omitted objects.
> +to yourself the runtime effect of tracking all omitted objects.
>
> === Changing the Order
>
> diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> index 3da4ea98e2..00fcc9d7c7 100644
> --- a/Documentation/config/pack.txt
> +++ b/Documentation/config/pack.txt
> @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> This cache is used to speed up the writing object phase by not
> having to recompute the final delta result once the best match
> for all objects is found. Repacking large repositories on machines
> - which are tight with memory might be badly impacted by this though,
> + which are tight with memory might be badly affected by this though,
> especially if this cache pushes the system into swapping.
> A value of 0 means no limit. The smallest size of 1 byte may be
> used to virtually disable this cache. Defaults to 256 MiB.
> diff --git a/Documentation/git-fast-import.txt
> b/Documentation/git-fast-import.txt
> index 39cfa05b28..c6d8e4e1d7 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -58,7 +58,7 @@ OPTIONS
> allowing fast-import to access the filesystem outside of the
> repository). These options are disabled by default, but can be
> allowed by providing this option on the command line. This
> - currently impacts only the `export-marks`, `import-marks`, and
> + currently affects only the `export-marks`, `import-marks`, and
> `import-marks-if-exists` feature commands.
> +
> Only enable this option if you trust the program generating the
> @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
>
> A `filecopy` command takes effect immediately. Once the source
> location has been copied to the destination any future commands
> -applied to the source location will not impact the destination of
> +applied to the source location will not affect the destination of
> the copy.
>
> `filerename`
> @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> A `filerename` command takes effect immediately. Once the source
> location has been renamed to the destination any future commands
> applied to the source location will create new files there and not
> -impact the destination of the rename.
> +affect the destination of the rename.
>
> Note that a `filerename` is the same as a `filecopy` followed by a
> `filedelete` of the source location. There is a slight performance
> @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> to be required).
> ~~~~~~~~~~
> Causes fast-import to print the entire `progress` line unmodified to
> its standard output channel (file descriptor 1) when the command is
> -processed from the input stream. The command otherwise has no impact
> +processed from the input stream. The command otherwise has no effect
> on the current import, or on any of fast-import's internal state.
>
> ....
> @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> ~~~~~~~~~~
> Causes fast-import to print the SHA-1 corresponding to a mark to
> stdout or to the file descriptor previously arranged with the
> -`--cat-blob-fd` argument. The command otherwise has no impact on the
> +`--cat-blob-fd` argument. The command otherwise has no effect on the
> current import; its purpose is to retrieve SHA-1s that later commits
> might want to refer to in their commit messages.
>
> @@ -1050,7 +1050,7 @@ this output safely.
> ~~~~~~~~~~
> Causes fast-import to print a blob to a file descriptor previously
> arranged with the `--cat-blob-fd` argument. The command otherwise
> -has no impact on the current import; its main purpose is to
> +has no effect on the current import; its main purpose is to
> retrieve blobs that may be in fast-import's memory but not
> accessible from the target repository.
>
> @@ -1366,7 +1366,7 @@ code considerably.
>
> The branch LRU builtin to fast-import tends to behave very well, and the
> cost of activating an inactive branch is so low that bouncing around
> -between branches has virtually no impact on import performance.
> +between branches has virtually no effect on import performance.
>
> Handling Renames
> ~~~~~~~~~~~~~~~~
> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> index 9067c2079e..01cf3b3d16 100644
> --- a/Documentation/git-fetch.txt
> +++ b/Documentation/git-fetch.txt
> @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> If left to accumulate, these stale references might make performance
> worse on big and busy repos that have a lot of branch churn, and
> e.g. make the output of commands like `git branch -a --contains
> -<commit>` needlessly verbose, as well as impacting anything else
> +<commit>` needlessly verbose, as well as affecting anything else
> that'll work with the complete set of known references.
>
> These remote-tracking references can be deleted as a one-off with
> diff --git a/Documentation/technical/hash-function-transition.txt
> b/Documentation/technical/hash-function-transition.txt
> index 7c1630bf83..f4296faffc 100644
> --- a/Documentation/technical/hash-function-transition.txt
> +++ b/Documentation/technical/hash-function-transition.txt
> @@ -42,7 +42,7 @@ mitigations.
>
> If SHA-1 and its variants were to be truly broken, Git's hash function
> could not be considered cryptographically secure any more. This would
> -impact the communication of hash values because we could not trust
> +affect the communication of hash values because we could not trust
> that a given hash value represented the known good version of content
> that the speaker intended.
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index fd480b8645..33c60c49d7 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> -state without impacting any branches by performing another switch.
> +state without affecting any branches by performing another switch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command again. Example:
> @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> overwritten by the result of
> the merge when this combining is done cleanly, or overwritten by a
> half-merged results when this combining results in conflicts.
> Therefore, if you have uncommitted changes touching the same files as
> -the ones impacted by the merge, Git will refuse to proceed. Most of
> +the ones affected by the merge, Git will refuse to proceed. Most of
> the time, you will want to commit your changes before you can merge,
> and if you don't, then linkgit:git-stash[1] can take these changes
> away while you're doing the merge, and reapply them afterwards.
> diff --git a/advice.c b/advice.c
> index 164742305f..9cbbb824a9 100644
> --- a/advice.c
> +++ b/advice.c
> @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> "\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/builtin/fast-import.c b/builtin/fast-import.c
> index 3afa81cf9a..24f362d2f4 100644
> --- a/builtin/fast-import.c
> +++ b/builtin/fast-import.c
> @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> const char *prefix)
> * We don't parse most options until after we've seen the set of
> * "feature" lines at the start of the stream (which allows the command
> * line to override stream data). But we must do an early parse of any
> - * command-line options that impact how we interpret the feature lines.
> + * command-line options that affect how we interpret the feature lines.
> */
> for (i = 1; i < argc; i++) {
> const char *arg = argv[i];
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index 525c2d8552..749bbca241 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> /*
> * Mark ourselves as active and see if the next step causes
> * us to cycle to another active object. It's important to do
> - * this _before_ we loop, because it impacts where we make the
> + * this _before_ we loop, because it affects where we make the
> * cut, and thus how our total_depth counter works.
> * E.g., We may see a partial loop like:
> *
> diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h
> index 814845d4b3..de13121d76 100644
> --- a/compat/nedmalloc/malloc.c.h
> +++ b/compat/nedmalloc/malloc.c.h
> @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> #endif /* (FOOTERS && !INSECURE) */
>
>
> -/* In gcc, use __builtin_expect to minimize impact of checks */
> +/* In gcc, use __builtin_expect to minimize affect of checks */
> #if !INSECURE
> #if defined(__GNUC__) && __GNUC__ >= 3
> #define RTCHECK(e) __builtin_expect(e, 1)
> diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> index f0e80bd7f0..92979ec770 100644
> --- a/contrib/coccinelle/README
> +++ b/contrib/coccinelle/README
> @@ -40,4 +40,4 @@ There are two types of semantic patches:
> are ignored for checks, and can be applied using 'make coccicheck-pending'.
>
> This allows to expose plans of pending large scale refactorings without
> - impacting the bad pattern checks.
> + affecting the bad pattern checks.
> diff --git a/dir.c b/dir.c
> index 3474e67e8f..235e26a90e 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -2144,7 +2144,7 @@ static enum path_treatment
> treat_path_fast(struct dir_struct *dir,
> /*
> * We get path_recurse in the first run when
> * directory_exists_in_index() returns index_nonexistent. We
> - * are sure that new changes in the index does not impact the
> + * are sure that new changes in the index does not affect the
> * outcome. Return now.
> */
> return path_recurse;
> diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> index d0e0e019ea..1fcb98443c 100755
> --- a/t/perf/p5550-fetch-tags.sh
> +++ b/t/perf/p5550-fetch-tags.sh
> @@ -8,7 +8,7 @@ follows.
>
> The parent repository has a large number of tags which are disconnected from
> the rest of history. That makes them candidates for tag-following, but we never
> -actually grab them (and thus they will impact each subsequent fetch).
> +actually grab them (and thus they will affect each subsequent fetch).
>
> The child repository is a clone of parent, without the tags, and is at least
> one commit behind the parent (meaning that we will fetch one object and then
> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> index a594b4aa7d..95daba4000 100755
> --- a/t/t0008-ignores.sh
> +++ b/t/t0008-ignores.sh
> @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> # test standard ignores
>
> # First make sure that the presence of a file in the working tree
> -# does not impact results, but that the presence of a file in the
> +# does not affect results, but that the presence of a file in the
> # index does unless the --no-index option is used.
>
> for subdir in '' 'a/'
> diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> index f028fd1418..a9348f655a 100755
> --- a/t/t0303-credential-external.sh
> +++ b/t/t0303-credential-external.sh
> @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
>
> # clean before the test in case there is cruft left
> -# over from a previous run that would impact results
> +# over from a previous run that would affect results
> helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
>
> helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> index bc46713a43..568c258c5a 100755
> --- a/t/t2020-checkout-detach.sh
> +++ b/t/t2020-checkout-detach.sh
> @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> no SHA-1 ellipsis when not as
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> - state without impacting any branches by switching back to a branch.
> + state without affecting any branches by switching back to a branch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command. Example:
> @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> print SHA-1 ellipsis when asked
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> - state without impacting any branches by switching back to a branch.
> + state without affecting any branches by switching back to a branch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command. Example:
> diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> index 6cca8b84a6..97365a7786 100755
> --- a/t/t4013-diff-various.sh
> +++ b/t/t4013-diff-various.sh
> @@ -109,7 +109,7 @@ test_expect_success setup '
> git checkout -f master &&
>
> # Same merge as master, but with parents reversed. Hide it in a
> - # pseudo-ref to avoid impacting tests with --all.
> + # pseudo-ref to avoid affecting tests with --all.
> commit=$(echo reverse |
> git commit-tree -p master^2 -p master^1 master^{tree}) &&
> git update-ref REVERSE $commit &&
> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> index 7204799a0b..33a6efce2f 100755
> --- a/t/t5000-tar-tree.sh
> +++ b/t/t5000-tar-tree.sh
> @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> # Pull the size and date of each entry in a tarfile using the system tar.
> #
> # We'll pull out only the year from the date; that avoids any question of
> -# timezones impacting the result (as long as we keep our test times away from a
> +# timezones affecting the result (as long as we keep our test times away from a
> # year boundary; our reference times are all in August).
> #
> # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index 6348e8d733..ff65f86f50 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> }
>
> # Like "env FOO=BAR some-program", but run inside a subshell, which means
> -# it also works for shell functions (though those functions cannot impact
> +# it also works for shell functions (though those functions cannot affect
> # the environment outside of the test_env invocation).
> test_env () {
> (
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-06 9:24 ` Michal Suchánek
@ 2021-04-06 19:36 ` Varun Varada
2021-04-06 23:01 ` Jeff King
2021-05-11 19:59 ` Felipe Contreras
2021-05-11 19:21 ` Felipe Contreras
1 sibling, 2 replies; 68+ messages in thread
From: Varun Varada @ 2021-04-06 19:36 UTC (permalink / raw)
To: Michal Suchánek; +Cc: git
On Tue, 6 Apr 2021 at 04:24, Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Mon, Apr 05, 2021 at 04:48:58PM -0500, Varun Varada wrote:
> > There are a bunch of places in the code/docs which use the word "impact"
> > incorrectly. This is especially true of places where it says "will not
> > impact", which suggests that it might have an effect, albeit not as
> > strong of a one. This commit replaces all of these with their
> > appropriate alternative so that the docs not only does not use jargon,
> > but are also unambiguous.
>
> Hello,
>
> while using "will not impact" in an incorrect or unclear way may be a
> problem the word "impact" in itself is not "jargon".
The word means "to have a strong or marked effect on" (v.) and "a
strong or market influence" (n.) when used figuratively; it is not
synonymous with "affect" and "effect", respectively, as shown even by
all of the entries you've cited. Using it as such is the incorrect
part, so those are the instances I've changed in the diff.
>
> From The Collaborative International Dictionary of English v.0.48 :
>
> Impact \Im*pact"\, v. t. [imp. & p. p. Impacted; p. pr. & vb.
> n. Impacting.] [L. impactus, p. p. of impingere to push,
> strike against. See Impinge.]
> 1. To drive close; to press firmly together: to wedge into a
> place. --Woodward.
> [1913 Webster]
>
> 2. To affect or influence, especially in a significant or
> undesirable manner; as, budget cuts impacted the entire
> research program; the fish populations were adversely
> impacted by pollution.
> [PJC]
>
> 3. To collide forcefully with; to strike.
> [PJC]
>
> From WordNet (r) 3.0 (2006) :
>
> impact
> n 1: the striking of one body against another
> 2: a forceful consequence; a strong effect; "the book had an
> important impact on my thinking"; "the book packs a wallop"
> [syn: impact, wallop]
> 3: influencing strongly; "they resented the impingement of
> American values on European culture" [syn: impingement,
> encroachment, impact]
> 4: the violent interaction of individuals or groups entering
> into combat; "the armies met in the shock of battle" [syn:
> shock, impact]
> v 1: press or wedge together; pack together
> 2: have an effect upon; "Will the new rules affect me?" [syn:
> affect, impact, bear upon, bear on, touch on,
> touch]
>
> From Merriam-Webster dictionary:
>
> impact
>
> noun
> im·pact | \ ˈim-ˌpakt How to pronounce impact (audio) \
> plural impacts
>
> 1a : an impinging or striking especially of one body against another
> b : a forceful contact or onset also : the impetus communicated in or as
> if in such a contact
> 2 : the force of impression of one thing on another : a significant or
> major effect the impact of science on our society a study outlining the
> potential environmental impacts of the construction project
>
> impact
>
> verb
> im·pact | \ im-ˈpakt How to pronounce impact (audio) \
> impacted; impacting; impacts
>
> transitive verb
>
> 1a : to have a direct effect or impact on : impinge on
> b : to strike forcefully also : to cause to strike forcefully
> 2a : to fix firmly by or as if by packing or wedging
> b : to press together
>
> intransitive verb
>
> 1 : to have an impact —often used with on
> 2 : to impinge or make contact especially forcefully
>
> If you are concerned about correctness and clarity of the documentation please
> avoid spreading misinformation.
As for jargon, using the noun and the verb in a figurative sense is
still in the realm of (business) jargon for most publications:
From Lexico, powered by Oxford English Dictionary:
The phrasal verb impact on, as in when produce is lost, it always
impacts on the bottom line, has been in the language since the 1960s.
Many people disapprove of it, saying that make an impact on or other
equivalent wordings should be used instead. This may be partly
because, in general, new formations of verbs from nouns (as in the
case of impact, action, and task) are regarded as somehow inferior; in
addition, since the verbal use of impact is associated with business
and commercial writing, it has the unenviable status of ‘jargon’,
which makes it doubly disliked.
From the Modern Language Association (MLA):
In its publications, the MLA follows various usage experts who
recommend restricting the use of impact as a verb to only one of the
several definitions you may find in a dictionary: “to strike
forcefully” (“Impact”). A car may impact another car in a collision,
for example. But we avoid using impact as a verb when the meaning is
“to affect” or “to influence.”
From MIT / the Mayfield Handbook of Technical and Scientific Writing:
Do not confuse the words affect, effect, and impact, each of which can
be used both as a verb and as a noun. Avoid incorrectly using impact
as a verb in place of affect or as a noun in place of effect.
>
> Thanks
>
> Michal
>
> > Signed-off-by: Varun Varada <varuncvarada@gmail.com>
> > ---
> > Documentation/MyFirstContribution.txt | 2 +-
> > Documentation/MyFirstObjectWalk.txt | 2 +-
> > Documentation/config/pack.txt | 2 +-
> > Documentation/git-fast-import.txt | 14 +++++++-------
> > Documentation/git-fetch.txt | 2 +-
> > .../technical/hash-function-transition.txt | 2 +-
> > Documentation/user-manual.txt | 4 ++--
> > advice.c | 2 +-
> > builtin/fast-import.c | 2 +-
> > builtin/pack-objects.c | 2 +-
> > compat/nedmalloc/malloc.c.h | 2 +-
> > contrib/coccinelle/README | 2 +-
> > dir.c | 2 +-
> > t/perf/p5550-fetch-tags.sh | 2 +-
> > t/t0008-ignores.sh | 2 +-
> > t/t0303-credential-external.sh | 2 +-
> > t/t2020-checkout-detach.sh | 4 ++--
> > t/t4013-diff-various.sh | 2 +-
> > t/t5000-tar-tree.sh | 2 +-
> > t/test-lib-functions.sh | 2 +-
> > 20 files changed, 28 insertions(+), 28 deletions(-)
> >
> > diff --git a/Documentation/MyFirstContribution.txt
> > b/Documentation/MyFirstContribution.txt
> > index af0a9da62e..8372a7e59e 100644
> > --- a/Documentation/MyFirstContribution.txt
> > +++ b/Documentation/MyFirstContribution.txt
> > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> > how to show it in the general
> > command list shown by `git help git` or `git help -a`, which is generated from
> > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> > line above it in alphabetical order. Now, we can add some attributes about the
> > -command which impacts where it shows up in the aforementioned help
> > commands. The
> > +command which affects where it shows up in the aforementioned help
> > commands. The
> > top of `command-list.txt` shares some information about what each attribute
> > means; in those help pages, the commands are sorted according to these
> > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> > diff --git a/Documentation/MyFirstObjectWalk.txt
> > b/Documentation/MyFirstObjectWalk.txt
> > index 2d10eea7a9..fd5bb8fb7d 100644
> > --- a/Documentation/MyFirstObjectWalk.txt
> > +++ b/Documentation/MyFirstObjectWalk.txt
> > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> > By running your walk with and without the filter, you should find
> > that the total
> > object count in each case is identical. You can also time each invocation of
> > the `walken` subcommand, with and without `omitted` being passed in, to confirm
> > -to yourself the runtime impact of tracking all omitted objects.
> > +to yourself the runtime effect of tracking all omitted objects.
> >
> > === Changing the Order
> >
> > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> > index 3da4ea98e2..00fcc9d7c7 100644
> > --- a/Documentation/config/pack.txt
> > +++ b/Documentation/config/pack.txt
> > @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> > This cache is used to speed up the writing object phase by not
> > having to recompute the final delta result once the best match
> > for all objects is found. Repacking large repositories on machines
> > - which are tight with memory might be badly impacted by this though,
> > + which are tight with memory might be badly affected by this though,
> > especially if this cache pushes the system into swapping.
> > A value of 0 means no limit. The smallest size of 1 byte may be
> > used to virtually disable this cache. Defaults to 256 MiB.
> > diff --git a/Documentation/git-fast-import.txt
> > b/Documentation/git-fast-import.txt
> > index 39cfa05b28..c6d8e4e1d7 100644
> > --- a/Documentation/git-fast-import.txt
> > +++ b/Documentation/git-fast-import.txt
> > @@ -58,7 +58,7 @@ OPTIONS
> > allowing fast-import to access the filesystem outside of the
> > repository). These options are disabled by default, but can be
> > allowed by providing this option on the command line. This
> > - currently impacts only the `export-marks`, `import-marks`, and
> > + currently affects only the `export-marks`, `import-marks`, and
> > `import-marks-if-exists` feature commands.
> > +
> > Only enable this option if you trust the program generating the
> > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
> >
> > A `filecopy` command takes effect immediately. Once the source
> > location has been copied to the destination any future commands
> > -applied to the source location will not impact the destination of
> > +applied to the source location will not affect the destination of
> > the copy.
> >
> > `filerename`
> > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> > A `filerename` command takes effect immediately. Once the source
> > location has been renamed to the destination any future commands
> > applied to the source location will create new files there and not
> > -impact the destination of the rename.
> > +affect the destination of the rename.
> >
> > Note that a `filerename` is the same as a `filecopy` followed by a
> > `filedelete` of the source location. There is a slight performance
> > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> > to be required).
> > ~~~~~~~~~~
> > Causes fast-import to print the entire `progress` line unmodified to
> > its standard output channel (file descriptor 1) when the command is
> > -processed from the input stream. The command otherwise has no impact
> > +processed from the input stream. The command otherwise has no effect
> > on the current import, or on any of fast-import's internal state.
> >
> > ....
> > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> > ~~~~~~~~~~
> > Causes fast-import to print the SHA-1 corresponding to a mark to
> > stdout or to the file descriptor previously arranged with the
> > -`--cat-blob-fd` argument. The command otherwise has no impact on the
> > +`--cat-blob-fd` argument. The command otherwise has no effect on the
> > current import; its purpose is to retrieve SHA-1s that later commits
> > might want to refer to in their commit messages.
> >
> > @@ -1050,7 +1050,7 @@ this output safely.
> > ~~~~~~~~~~
> > Causes fast-import to print a blob to a file descriptor previously
> > arranged with the `--cat-blob-fd` argument. The command otherwise
> > -has no impact on the current import; its main purpose is to
> > +has no effect on the current import; its main purpose is to
> > retrieve blobs that may be in fast-import's memory but not
> > accessible from the target repository.
> >
> > @@ -1366,7 +1366,7 @@ code considerably.
> >
> > The branch LRU builtin to fast-import tends to behave very well, and the
> > cost of activating an inactive branch is so low that bouncing around
> > -between branches has virtually no impact on import performance.
> > +between branches has virtually no effect on import performance.
> >
> > Handling Renames
> > ~~~~~~~~~~~~~~~~
> > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> > index 9067c2079e..01cf3b3d16 100644
> > --- a/Documentation/git-fetch.txt
> > +++ b/Documentation/git-fetch.txt
> > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> > If left to accumulate, these stale references might make performance
> > worse on big and busy repos that have a lot of branch churn, and
> > e.g. make the output of commands like `git branch -a --contains
> > -<commit>` needlessly verbose, as well as impacting anything else
> > +<commit>` needlessly verbose, as well as affecting anything else
> > that'll work with the complete set of known references.
> >
> > These remote-tracking references can be deleted as a one-off with
> > diff --git a/Documentation/technical/hash-function-transition.txt
> > b/Documentation/technical/hash-function-transition.txt
> > index 7c1630bf83..f4296faffc 100644
> > --- a/Documentation/technical/hash-function-transition.txt
> > +++ b/Documentation/technical/hash-function-transition.txt
> > @@ -42,7 +42,7 @@ mitigations.
> >
> > If SHA-1 and its variants were to be truly broken, Git's hash function
> > could not be considered cryptographically secure any more. This would
> > -impact the communication of hash values because we could not trust
> > +affect the communication of hash values because we could not trust
> > that a given hash value represented the known good version of content
> > that the speaker intended.
> >
> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > index fd480b8645..33c60c49d7 100644
> > --- a/Documentation/user-manual.txt
> > +++ b/Documentation/user-manual.txt
> > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
> >
> > You are in 'detached HEAD' state. You can look around, make experimental
> > changes and commit them, and you can discard any commits you make in this
> > -state without impacting any branches by performing another switch.
> > +state without affecting any branches by performing another switch.
> >
> > If you want to create a new branch to retain commits you create, you may
> > do so (now or later) by using -c with the switch command again. Example:
> > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> > overwritten by the result of
> > the merge when this combining is done cleanly, or overwritten by a
> > half-merged results when this combining results in conflicts.
> > Therefore, if you have uncommitted changes touching the same files as
> > -the ones impacted by the merge, Git will refuse to proceed. Most of
> > +the ones affected by the merge, Git will refuse to proceed. Most of
> > the time, you will want to commit your changes before you can merge,
> > and if you don't, then linkgit:git-stash[1] can take these changes
> > away while you're doing the merge, and reapply them afterwards.
> > diff --git a/advice.c b/advice.c
> > index 164742305f..9cbbb824a9 100644
> > --- a/advice.c
> > +++ b/advice.c
> > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> > "\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/builtin/fast-import.c b/builtin/fast-import.c
> > index 3afa81cf9a..24f362d2f4 100644
> > --- a/builtin/fast-import.c
> > +++ b/builtin/fast-import.c
> > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> > const char *prefix)
> > * We don't parse most options until after we've seen the set of
> > * "feature" lines at the start of the stream (which allows the command
> > * line to override stream data). But we must do an early parse of any
> > - * command-line options that impact how we interpret the feature lines.
> > + * command-line options that affect how we interpret the feature lines.
> > */
> > for (i = 1; i < argc; i++) {
> > const char *arg = argv[i];
> > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> > index 525c2d8552..749bbca241 100644
> > --- a/builtin/pack-objects.c
> > +++ b/builtin/pack-objects.c
> > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> > /*
> > * Mark ourselves as active and see if the next step causes
> > * us to cycle to another active object. It's important to do
> > - * this _before_ we loop, because it impacts where we make the
> > + * this _before_ we loop, because it affects where we make the
> > * cut, and thus how our total_depth counter works.
> > * E.g., We may see a partial loop like:
> > *
> > diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h
> > index 814845d4b3..de13121d76 100644
> > --- a/compat/nedmalloc/malloc.c.h
> > +++ b/compat/nedmalloc/malloc.c.h
> > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > #endif /* (FOOTERS && !INSECURE) */
> >
> >
> > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > #if !INSECURE
> > #if defined(__GNUC__) && __GNUC__ >= 3
> > #define RTCHECK(e) __builtin_expect(e, 1)
> > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> > index f0e80bd7f0..92979ec770 100644
> > --- a/contrib/coccinelle/README
> > +++ b/contrib/coccinelle/README
> > @@ -40,4 +40,4 @@ There are two types of semantic patches:
> > are ignored for checks, and can be applied using 'make coccicheck-pending'.
> >
> > This allows to expose plans of pending large scale refactorings without
> > - impacting the bad pattern checks.
> > + affecting the bad pattern checks.
> > diff --git a/dir.c b/dir.c
> > index 3474e67e8f..235e26a90e 100644
> > --- a/dir.c
> > +++ b/dir.c
> > @@ -2144,7 +2144,7 @@ static enum path_treatment
> > treat_path_fast(struct dir_struct *dir,
> > /*
> > * We get path_recurse in the first run when
> > * directory_exists_in_index() returns index_nonexistent. We
> > - * are sure that new changes in the index does not impact the
> > + * are sure that new changes in the index does not affect the
> > * outcome. Return now.
> > */
> > return path_recurse;
> > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> > index d0e0e019ea..1fcb98443c 100755
> > --- a/t/perf/p5550-fetch-tags.sh
> > +++ b/t/perf/p5550-fetch-tags.sh
> > @@ -8,7 +8,7 @@ follows.
> >
> > The parent repository has a large number of tags which are disconnected from
> > the rest of history. That makes them candidates for tag-following, but we never
> > -actually grab them (and thus they will impact each subsequent fetch).
> > +actually grab them (and thus they will affect each subsequent fetch).
> >
> > The child repository is a clone of parent, without the tags, and is at least
> > one commit behind the parent (meaning that we will fetch one object and then
> > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> > index a594b4aa7d..95daba4000 100755
> > --- a/t/t0008-ignores.sh
> > +++ b/t/t0008-ignores.sh
> > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> > # test standard ignores
> >
> > # First make sure that the presence of a file in the working tree
> > -# does not impact results, but that the presence of a file in the
> > +# does not affect results, but that the presence of a file in the
> > # index does unless the --no-index option is used.
> >
> > for subdir in '' 'a/'
> > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> > index f028fd1418..a9348f655a 100755
> > --- a/t/t0303-credential-external.sh
> > +++ b/t/t0303-credential-external.sh
> > @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> > eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
> >
> > # clean before the test in case there is cruft left
> > -# over from a previous run that would impact results
> > +# over from a previous run that would affect results
> > helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
> >
> > helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> > index bc46713a43..568c258c5a 100755
> > --- a/t/t2020-checkout-detach.sh
> > +++ b/t/t2020-checkout-detach.sh
> > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> > no SHA-1 ellipsis when not as
> >
> > You are in 'detached HEAD' state. You can look around, make experimental
> > changes and commit them, and you can discard any commits you make in this
> > - state without impacting any branches by switching back to a branch.
> > + state without affecting any branches by switching back to a branch.
> >
> > If you want to create a new branch to retain commits you create, you may
> > do so (now or later) by using -c with the switch command. Example:
> > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> > print SHA-1 ellipsis when asked
> >
> > You are in 'detached HEAD' state. You can look around, make experimental
> > changes and commit them, and you can discard any commits you make in this
> > - state without impacting any branches by switching back to a branch.
> > + state without affecting any branches by switching back to a branch.
> >
> > If you want to create a new branch to retain commits you create, you may
> > do so (now or later) by using -c with the switch command. Example:
> > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> > index 6cca8b84a6..97365a7786 100755
> > --- a/t/t4013-diff-various.sh
> > +++ b/t/t4013-diff-various.sh
> > @@ -109,7 +109,7 @@ test_expect_success setup '
> > git checkout -f master &&
> >
> > # Same merge as master, but with parents reversed. Hide it in a
> > - # pseudo-ref to avoid impacting tests with --all.
> > + # pseudo-ref to avoid affecting tests with --all.
> > commit=$(echo reverse |
> > git commit-tree -p master^2 -p master^1 master^{tree}) &&
> > git update-ref REVERSE $commit &&
> > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> > index 7204799a0b..33a6efce2f 100755
> > --- a/t/t5000-tar-tree.sh
> > +++ b/t/t5000-tar-tree.sh
> > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> > # Pull the size and date of each entry in a tarfile using the system tar.
> > #
> > # We'll pull out only the year from the date; that avoids any question of
> > -# timezones impacting the result (as long as we keep our test times away from a
> > +# timezones affecting the result (as long as we keep our test times away from a
> > # year boundary; our reference times are all in August).
> > #
> > # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> > index 6348e8d733..ff65f86f50 100644
> > --- a/t/test-lib-functions.sh
> > +++ b/t/test-lib-functions.sh
> > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> > }
> >
> > # Like "env FOO=BAR some-program", but run inside a subshell, which means
> > -# it also works for shell functions (though those functions cannot impact
> > +# it also works for shell functions (though those functions cannot affect
> > # the environment outside of the test_env invocation).
> > test_env () {
> > (
> > --
> > 2.17.1
> >
> >
> > From varun Mon Apr 5 16:45:37 2021
> > Return-Path: <varun>
> > Received: (from varun@localhost)
> > by black-diamond (8.15.2/8.15.2/Submit) id 135LjbIS027022;
> > Mon, 5 Apr 2021 16:45:37 -0500
> > From: Varun Varada <varuncvarada@gmail.com>
> > To: git@vger.kernel.org
> > Cc: Varun Varada <varuncvarada@gmail.com>
> > Subject: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
> > Date: Mon, 5 Apr 2021 16:44:35 -0500
> > Message-Id: <20210405214435.26979-1-varuncvarada@gmail.com>
> > X-Mailer: git-send-email 2.17.1
> >
> > There are a bunch of places in the code/docs which use the word "impact"
> > incorrectly. This is especially true of places where it says "will not
> > impact", which suggests that it might have an effect, albeit not as
> > strong of a one. This commit replaces all of these with their
> > appropriate alternative so that the docs not only does not use jargon,
> > but are also unambiguous.
> >
> > Signed-off-by: Varun Varada <varuncvarada@gmail.com>
> > ---
> > Documentation/MyFirstContribution.txt | 2 +-
> > Documentation/MyFirstObjectWalk.txt | 2 +-
> > Documentation/config/pack.txt | 2 +-
> > Documentation/git-fast-import.txt | 14 +++++++-------
> > Documentation/git-fetch.txt | 2 +-
> > .../technical/hash-function-transition.txt | 2 +-
> > Documentation/user-manual.txt | 4 ++--
> > advice.c | 2 +-
> > builtin/fast-import.c | 2 +-
> > builtin/pack-objects.c | 2 +-
> > compat/nedmalloc/malloc.c.h | 2 +-
> > contrib/coccinelle/README | 2 +-
> > dir.c | 2 +-
> > t/perf/p5550-fetch-tags.sh | 2 +-
> > t/t0008-ignores.sh | 2 +-
> > t/t0303-credential-external.sh | 2 +-
> > t/t2020-checkout-detach.sh | 4 ++--
> > t/t4013-diff-various.sh | 2 +-
> > t/t5000-tar-tree.sh | 2 +-
> > t/test-lib-functions.sh | 2 +-
> > 20 files changed, 28 insertions(+), 28 deletions(-)
> >
> > diff --git a/Documentation/MyFirstContribution.txt
> > b/Documentation/MyFirstContribution.txt
> > index af0a9da62e..8372a7e59e 100644
> > --- a/Documentation/MyFirstContribution.txt
> > +++ b/Documentation/MyFirstContribution.txt
> > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> > how to show it in the general
> > command list shown by `git help git` or `git help -a`, which is generated from
> > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> > line above it in alphabetical order. Now, we can add some attributes about the
> > -command which impacts where it shows up in the aforementioned help
> > commands. The
> > +command which affects where it shows up in the aforementioned help
> > commands. The
> > top of `command-list.txt` shares some information about what each attribute
> > means; in those help pages, the commands are sorted according to these
> > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> > diff --git a/Documentation/MyFirstObjectWalk.txt
> > b/Documentation/MyFirstObjectWalk.txt
> > index 2d10eea7a9..fd5bb8fb7d 100644
> > --- a/Documentation/MyFirstObjectWalk.txt
> > +++ b/Documentation/MyFirstObjectWalk.txt
> > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> > By running your walk with and without the filter, you should find
> > that the total
> > object count in each case is identical. You can also time each invocation of
> > the `walken` subcommand, with and without `omitted` being passed in, to confirm
> > -to yourself the runtime impact of tracking all omitted objects.
> > +to yourself the runtime effect of tracking all omitted objects.
> >
> > === Changing the Order
> >
> > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> > index 3da4ea98e2..00fcc9d7c7 100644
> > --- a/Documentation/config/pack.txt
> > +++ b/Documentation/config/pack.txt
> > @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> > This cache is used to speed up the writing object phase by not
> > having to recompute the final delta result once the best match
> > for all objects is found. Repacking large repositories on machines
> > - which are tight with memory might be badly impacted by this though,
> > + which are tight with memory might be badly affected by this though,
> > especially if this cache pushes the system into swapping.
> > A value of 0 means no limit. The smallest size of 1 byte may be
> > used to virtually disable this cache. Defaults to 256 MiB.
> > diff --git a/Documentation/git-fast-import.txt
> > b/Documentation/git-fast-import.txt
> > index 39cfa05b28..c6d8e4e1d7 100644
> > --- a/Documentation/git-fast-import.txt
> > +++ b/Documentation/git-fast-import.txt
> > @@ -58,7 +58,7 @@ OPTIONS
> > allowing fast-import to access the filesystem outside of the
> > repository). These options are disabled by default, but can be
> > allowed by providing this option on the command line. This
> > - currently impacts only the `export-marks`, `import-marks`, and
> > + currently affects only the `export-marks`, `import-marks`, and
> > `import-marks-if-exists` feature commands.
> > +
> > Only enable this option if you trust the program generating the
> > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
> >
> > A `filecopy` command takes effect immediately. Once the source
> > location has been copied to the destination any future commands
> > -applied to the source location will not impact the destination of
> > +applied to the source location will not affect the destination of
> > the copy.
> >
> > `filerename`
> > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> > A `filerename` command takes effect immediately. Once the source
> > location has been renamed to the destination any future commands
> > applied to the source location will create new files there and not
> > -impact the destination of the rename.
> > +affect the destination of the rename.
> >
> > Note that a `filerename` is the same as a `filecopy` followed by a
> > `filedelete` of the source location. There is a slight performance
> > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> > to be required).
> > ~~~~~~~~~~
> > Causes fast-import to print the entire `progress` line unmodified to
> > its standard output channel (file descriptor 1) when the command is
> > -processed from the input stream. The command otherwise has no impact
> > +processed from the input stream. The command otherwise has no effect
> > on the current import, or on any of fast-import's internal state.
> >
> > ....
> > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> > ~~~~~~~~~~
> > Causes fast-import to print the SHA-1 corresponding to a mark to
> > stdout or to the file descriptor previously arranged with the
> > -`--cat-blob-fd` argument. The command otherwise has no impact on the
> > +`--cat-blob-fd` argument. The command otherwise has no effect on the
> > current import; its purpose is to retrieve SHA-1s that later commits
> > might want to refer to in their commit messages.
> >
> > @@ -1050,7 +1050,7 @@ this output safely.
> > ~~~~~~~~~~
> > Causes fast-import to print a blob to a file descriptor previously
> > arranged with the `--cat-blob-fd` argument. The command otherwise
> > -has no impact on the current import; its main purpose is to
> > +has no effect on the current import; its main purpose is to
> > retrieve blobs that may be in fast-import's memory but not
> > accessible from the target repository.
> >
> > @@ -1366,7 +1366,7 @@ code considerably.
> >
> > The branch LRU builtin to fast-import tends to behave very well, and the
> > cost of activating an inactive branch is so low that bouncing around
> > -between branches has virtually no impact on import performance.
> > +between branches has virtually no effect on import performance.
> >
> > Handling Renames
> > ~~~~~~~~~~~~~~~~
> > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> > index 9067c2079e..01cf3b3d16 100644
> > --- a/Documentation/git-fetch.txt
> > +++ b/Documentation/git-fetch.txt
> > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> > If left to accumulate, these stale references might make performance
> > worse on big and busy repos that have a lot of branch churn, and
> > e.g. make the output of commands like `git branch -a --contains
> > -<commit>` needlessly verbose, as well as impacting anything else
> > +<commit>` needlessly verbose, as well as affecting anything else
> > that'll work with the complete set of known references.
> >
> > These remote-tracking references can be deleted as a one-off with
> > diff --git a/Documentation/technical/hash-function-transition.txt
> > b/Documentation/technical/hash-function-transition.txt
> > index 7c1630bf83..f4296faffc 100644
> > --- a/Documentation/technical/hash-function-transition.txt
> > +++ b/Documentation/technical/hash-function-transition.txt
> > @@ -42,7 +42,7 @@ mitigations.
> >
> > If SHA-1 and its variants were to be truly broken, Git's hash function
> > could not be considered cryptographically secure any more. This would
> > -impact the communication of hash values because we could not trust
> > +affect the communication of hash values because we could not trust
> > that a given hash value represented the known good version of content
> > that the speaker intended.
> >
> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > index fd480b8645..33c60c49d7 100644
> > --- a/Documentation/user-manual.txt
> > +++ b/Documentation/user-manual.txt
> > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
> >
> > You are in 'detached HEAD' state. You can look around, make experimental
> > changes and commit them, and you can discard any commits you make in this
> > -state without impacting any branches by performing another switch.
> > +state without affecting any branches by performing another switch.
> >
> > If you want to create a new branch to retain commits you create, you may
> > do so (now or later) by using -c with the switch command again. Example:
> > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> > overwritten by the result of
> > the merge when this combining is done cleanly, or overwritten by a
> > half-merged results when this combining results in conflicts.
> > Therefore, if you have uncommitted changes touching the same files as
> > -the ones impacted by the merge, Git will refuse to proceed. Most of
> > +the ones affected by the merge, Git will refuse to proceed. Most of
> > the time, you will want to commit your changes before you can merge,
> > and if you don't, then linkgit:git-stash[1] can take these changes
> > away while you're doing the merge, and reapply them afterwards.
> > diff --git a/advice.c b/advice.c
> > index 164742305f..9cbbb824a9 100644
> > --- a/advice.c
> > +++ b/advice.c
> > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> > "\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/builtin/fast-import.c b/builtin/fast-import.c
> > index 3afa81cf9a..24f362d2f4 100644
> > --- a/builtin/fast-import.c
> > +++ b/builtin/fast-import.c
> > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> > const char *prefix)
> > * We don't parse most options until after we've seen the set of
> > * "feature" lines at the start of the stream (which allows the command
> > * line to override stream data). But we must do an early parse of any
> > - * command-line options that impact how we interpret the feature lines.
> > + * command-line options that affect how we interpret the feature lines.
> > */
> > for (i = 1; i < argc; i++) {
> > const char *arg = argv[i];
> > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> > index 525c2d8552..749bbca241 100644
> > --- a/builtin/pack-objects.c
> > +++ b/builtin/pack-objects.c
> > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> > /*
> > * Mark ourselves as active and see if the next step causes
> > * us to cycle to another active object. It's important to do
> > - * this _before_ we loop, because it impacts where we make the
> > + * this _before_ we loop, because it affects where we make the
> > * cut, and thus how our total_depth counter works.
> > * E.g., We may see a partial loop like:
> > *
> > diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h
> > index 814845d4b3..de13121d76 100644
> > --- a/compat/nedmalloc/malloc.c.h
> > +++ b/compat/nedmalloc/malloc.c.h
> > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > #endif /* (FOOTERS && !INSECURE) */
> >
> >
> > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > #if !INSECURE
> > #if defined(__GNUC__) && __GNUC__ >= 3
> > #define RTCHECK(e) __builtin_expect(e, 1)
> > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> > index f0e80bd7f0..92979ec770 100644
> > --- a/contrib/coccinelle/README
> > +++ b/contrib/coccinelle/README
> > @@ -40,4 +40,4 @@ There are two types of semantic patches:
> > are ignored for checks, and can be applied using 'make coccicheck-pending'.
> >
> > This allows to expose plans of pending large scale refactorings without
> > - impacting the bad pattern checks.
> > + affecting the bad pattern checks.
> > diff --git a/dir.c b/dir.c
> > index 3474e67e8f..235e26a90e 100644
> > --- a/dir.c
> > +++ b/dir.c
> > @@ -2144,7 +2144,7 @@ static enum path_treatment
> > treat_path_fast(struct dir_struct *dir,
> > /*
> > * We get path_recurse in the first run when
> > * directory_exists_in_index() returns index_nonexistent. We
> > - * are sure that new changes in the index does not impact the
> > + * are sure that new changes in the index does not affect the
> > * outcome. Return now.
> > */
> > return path_recurse;
> > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> > index d0e0e019ea..1fcb98443c 100755
> > --- a/t/perf/p5550-fetch-tags.sh
> > +++ b/t/perf/p5550-fetch-tags.sh
> > @@ -8,7 +8,7 @@ follows.
> >
> > The parent repository has a large number of tags which are disconnected from
> > the rest of history. That makes them candidates for tag-following, but we never
> > -actually grab them (and thus they will impact each subsequent fetch).
> > +actually grab them (and thus they will affect each subsequent fetch).
> >
> > The child repository is a clone of parent, without the tags, and is at least
> > one commit behind the parent (meaning that we will fetch one object and then
> > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> > index a594b4aa7d..95daba4000 100755
> > --- a/t/t0008-ignores.sh
> > +++ b/t/t0008-ignores.sh
> > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> > # test standard ignores
> >
> > # First make sure that the presence of a file in the working tree
> > -# does not impact results, but that the presence of a file in the
> > +# does not affect results, but that the presence of a file in the
> > # index does unless the --no-index option is used.
> >
> > for subdir in '' 'a/'
> > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> > index f028fd1418..a9348f655a 100755
> > --- a/t/t0303-credential-external.sh
> > +++ b/t/t0303-credential-external.sh
> > @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> > eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
> >
> > # clean before the test in case there is cruft left
> > -# over from a previous run that would impact results
> > +# over from a previous run that would affect results
> > helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
> >
> > helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> > index bc46713a43..568c258c5a 100755
> > --- a/t/t2020-checkout-detach.sh
> > +++ b/t/t2020-checkout-detach.sh
> > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> > no SHA-1 ellipsis when not as
> >
> > You are in 'detached HEAD' state. You can look around, make experimental
> > changes and commit them, and you can discard any commits you make in this
> > - state without impacting any branches by switching back to a branch.
> > + state without affecting any branches by switching back to a branch.
> >
> > If you want to create a new branch to retain commits you create, you may
> > do so (now or later) by using -c with the switch command. Example:
> > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> > print SHA-1 ellipsis when asked
> >
> > You are in 'detached HEAD' state. You can look around, make experimental
> > changes and commit them, and you can discard any commits you make in this
> > - state without impacting any branches by switching back to a branch.
> > + state without affecting any branches by switching back to a branch.
> >
> > If you want to create a new branch to retain commits you create, you may
> > do so (now or later) by using -c with the switch command. Example:
> > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> > index 6cca8b84a6..97365a7786 100755
> > --- a/t/t4013-diff-various.sh
> > +++ b/t/t4013-diff-various.sh
> > @@ -109,7 +109,7 @@ test_expect_success setup '
> > git checkout -f master &&
> >
> > # Same merge as master, but with parents reversed. Hide it in a
> > - # pseudo-ref to avoid impacting tests with --all.
> > + # pseudo-ref to avoid affecting tests with --all.
> > commit=$(echo reverse |
> > git commit-tree -p master^2 -p master^1 master^{tree}) &&
> > git update-ref REVERSE $commit &&
> > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> > index 7204799a0b..33a6efce2f 100755
> > --- a/t/t5000-tar-tree.sh
> > +++ b/t/t5000-tar-tree.sh
> > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> > # Pull the size and date of each entry in a tarfile using the system tar.
> > #
> > # We'll pull out only the year from the date; that avoids any question of
> > -# timezones impacting the result (as long as we keep our test times away from a
> > +# timezones affecting the result (as long as we keep our test times away from a
> > # year boundary; our reference times are all in August).
> > #
> > # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> > index 6348e8d733..ff65f86f50 100644
> > --- a/t/test-lib-functions.sh
> > +++ b/t/test-lib-functions.sh
> > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> > }
> >
> > # Like "env FOO=BAR some-program", but run inside a subshell, which means
> > -# it also works for shell functions (though those functions cannot impact
> > +# it also works for shell functions (though those functions cannot affect
> > # the environment outside of the test_env invocation).
> > test_env () {
> > (
> > --
> > 2.17.1
> >
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-06 19:36 ` Varun Varada
@ 2021-04-06 23:01 ` Jeff King
2021-04-07 0:06 ` Varun Varada
2021-05-12 2:24 ` Felipe Contreras
2021-05-11 19:59 ` Felipe Contreras
1 sibling, 2 replies; 68+ messages in thread
From: Jeff King @ 2021-04-06 23:01 UTC (permalink / raw)
To: Varun Varada; +Cc: Michal Suchánek, git
On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
> > while using "will not impact" in an incorrect or unclear way may be a
> > problem the word "impact" in itself is not "jargon".
>
> The word means "to have a strong or marked effect on" (v.) and "a
> strong or market influence" (n.) when used figuratively; it is not
> synonymous with "affect" and "effect", respectively, as shown even by
> all of the entries you've cited. Using it as such is the incorrect
> part, so those are the instances I've changed in the diff.
Er, is that true? From Michal's definitions:
> > From The Collaborative International Dictionary of English v.0.48 :
> [...]
> > 2. To affect or influence, especially in a significant or
It literally uses "affect" to define it. The "especially significant"
does not apply to many, but I don't think that makes it necessarily
wrong to use impact to mean "affect".
Likewise:
> > From WordNet (r) 3.0 (2006) :
> [...]
> > v 1: press or wedge together; pack together
> > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > affect, impact, bear upon, bear on, touch on,
> > touch]
That is likewise listing "impact" and "affect" as synonyms.
I do agree the word is over-used in some forms of writing, but I don't
find anything at all confusing or wrong about the uses that you changed
in your patch. I am a native speaker of English. I'm open to the
argument that non-native speakers may be more confused by the word. But
this seems like mostly a style preference thing, and I'd generally
prefer to leave the contributions and style of the original writers
intact unless there is a good reason not to.
Such changes are doubly unwanted in cases like this:
> --- a/compat/nedmalloc/malloc.c.h
> +++ b/compat/nedmalloc/malloc.c.h
> @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> #endif /* (FOOTERS && !INSECURE) */
>
>
> -/* In gcc, use __builtin_expect to minimize impact of checks */
> +/* In gcc, use __builtin_expect to minimize affect of checks */
> #if !INSECURE
> #if defined(__GNUC__) && __GNUC__ >= 3
> #define RTCHECK(e) __builtin_expect(e, 1)
where the text is imported from another project, and we'd prefer to stay
as close to their version as possible (e.g., to avoid unnecessary
conflicts when pulling in new versions).
Also, this one should be "effect" anyway, as it is a noun.
-Peff
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-06 23:01 ` Jeff King
@ 2021-04-07 0:06 ` Varun Varada
2021-04-28 0:39 ` Varun Varada
2021-05-12 2:24 ` Felipe Contreras
1 sibling, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-04-07 0:06 UTC (permalink / raw)
To: Jeff King; +Cc: Michal Suchánek, git
On Tue, 6 Apr 2021 at 18:01, Jeff King <peff@peff.net> wrote:
>
> On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
>
> > > while using "will not impact" in an incorrect or unclear way may be a
> > > problem the word "impact" in itself is not "jargon".
> >
> > The word means "to have a strong or marked effect on" (v.) and "a
> > strong or market influence" (n.) when used figuratively; it is not
> > synonymous with "affect" and "effect", respectively, as shown even by
> > all of the entries you've cited. Using it as such is the incorrect
> > part, so those are the instances I've changed in the diff.
>
> Er, is that true? From Michal's definitions:
>
> > > From The Collaborative International Dictionary of English v.0.48 :
> > [...]
> > > 2. To affect or influence, especially in a significant or
>
> It literally uses "affect" to define it. The "especially significant"
> does not apply to many, but I don't think that makes it necessarily
> wrong to use impact to mean "affect".
I was drawing attention to the "especially significant" bit and the
like being there in all the entries. I'm not sure about these
dictionaries, but the definition is hyperbolic / violent / shocking in
every reputable dictionary out there: the Oxford English Dictionary,
Merriam-Webster, and Collins.
>
> Likewise:
>
> > > From WordNet (r) 3.0 (2006) :
> > [...]
> > > v 1: press or wedge together; pack together
> > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > affect, impact, bear upon, bear on, touch on,
> > > touch]
>
> That is likewise listing "impact" and "affect" as synonyms.
>
> I do agree the word is over-used in some forms of writing, but I don't
> find anything at all confusing or wrong about the uses that you changed
> in your patch. I am a native speaker of English. I'm open to the
> argument that non-native speakers may be more confused by the word. But
> this seems like mostly a style preference thing, and I'd generally
> prefer to leave the contributions and style of the original writers
> intact unless there is a good reason not to.
I am a native English speaker as well, and there were multiple places
where I had to think twice about what the sentences mean. I agree with
your sentiment about leaving stylistic preferences intact, but this is
actually a semantic one. And given that there is a perfectly good
alternative that doesn't have this confusion / jargon status, I wanted
to make the change to improve it, especially where it says that in the
output of the git command (`git checkout` when in detached HEAD mode).
>
> Such changes are doubly unwanted in cases like this:
>
> > --- a/compat/nedmalloc/malloc.c.h
> > +++ b/compat/nedmalloc/malloc.c.h
> > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > #endif /* (FOOTERS && !INSECURE) */
> >
> >
> > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > #if !INSECURE
> > #if defined(__GNUC__) && __GNUC__ >= 3
> > #define RTCHECK(e) __builtin_expect(e, 1)
>
> where the text is imported from another project, and we'd prefer to stay
> as close to their version as possible (e.g., to avoid unnecessary
> conflicts when pulling in new versions).
That's fair; I wasn't aware that this was being pulled directly from
another project. I can change this back.
>
> Also, this one should be "effect" anyway, as it is a noun.
This seems to have slipped through, as I used a text search tool.
>
> -Peff
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-07 0:06 ` Varun Varada
@ 2021-04-28 0:39 ` Varun Varada
2021-04-28 8:58 ` Michal Suchánek
0 siblings, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-04-28 0:39 UTC (permalink / raw)
To: Jeff King; +Cc: Michal Suchánek, git
Here's the updated diff:
Documentation/MyFirstContribution.txt | 2 +-
Documentation/MyFirstObjectWalk.txt | 2 +-
Documentation/config/pack.txt | 2 +-
Documentation/git-fast-import.txt | 14 +++++++-------
Documentation/git-fetch.txt | 2 +-
.../technical/hash-function-transition.txt | 2 +-
Documentation/user-manual.txt | 4 ++--
advice.c | 2 +-
builtin/fast-import.c | 2 +-
builtin/pack-objects.c | 2 +-
contrib/coccinelle/README | 2 +-
dir.c | 2 +-
t/perf/p5550-fetch-tags.sh | 2 +-
t/t0008-ignores.sh | 2 +-
t/t0303-credential-external.sh | 2 +-
t/t2020-checkout-detach.sh | 4 ++--
t/t4013-diff-various.sh | 2 +-
t/t5000-tar-tree.sh | 2 +-
t/test-lib-functions.sh | 2 +-
19 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/Documentation/MyFirstContribution.txt
b/Documentation/MyFirstContribution.txt
index af0a9da62e..8372a7e59e 100644
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
how to show it in the general
command list shown by `git help git` or `git help -a`, which is generated from
`command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
line above it in alphabetical order. Now, we can add some attributes about the
-command which impacts where it shows up in the aforementioned help
commands. The
+command which affects where it shows up in the aforementioned help
commands. The
top of `command-list.txt` shares some information about what each attribute
means; in those help pages, the commands are sorted according to these
attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
diff --git a/Documentation/MyFirstObjectWalk.txt
b/Documentation/MyFirstObjectWalk.txt
index 2d10eea7a9..fd5bb8fb7d 100644
--- a/Documentation/MyFirstObjectWalk.txt
+++ b/Documentation/MyFirstObjectWalk.txt
@@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
By running your walk with and without the filter, you should find
that the total
object count in each case is identical. You can also time each invocation of
the `walken` subcommand, with and without `omitted` being passed in, to confirm
-to yourself the runtime impact of tracking all omitted objects.
+to yourself the runtime effect of tracking all omitted objects.
=== Changing the Order
diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
index 3da4ea98e2..00fcc9d7c7 100644
--- a/Documentation/config/pack.txt
+++ b/Documentation/config/pack.txt
@@ -55,7 +55,7 @@ pack.deltaCacheSize::
This cache is used to speed up the writing object phase by not
having to recompute the final delta result once the best match
for all objects is found. Repacking large repositories on machines
- which are tight with memory might be badly impacted by this though,
+ which are tight with memory might be badly affected by this though,
especially if this cache pushes the system into swapping.
A value of 0 means no limit. The smallest size of 1 byte may be
used to virtually disable this cache. Defaults to 256 MiB.
diff --git a/Documentation/git-fast-import.txt
b/Documentation/git-fast-import.txt
index 39cfa05b28..c6d8e4e1d7 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -58,7 +58,7 @@ OPTIONS
allowing fast-import to access the filesystem outside of the
repository). These options are disabled by default, but can be
allowed by providing this option on the command line. This
- currently impacts only the `export-marks`, `import-marks`, and
+ currently affects only the `export-marks`, `import-marks`, and
`import-marks-if-exists` feature commands.
+
Only enable this option if you trust the program generating the
@@ -687,7 +687,7 @@ that contains SP the path must be quoted.
A `filecopy` command takes effect immediately. Once the source
location has been copied to the destination any future commands
-applied to the source location will not impact the destination of
+applied to the source location will not affect the destination of
the copy.
`filerename`
@@ -708,7 +708,7 @@ that contains SP the path must be quoted.
A `filerename` command takes effect immediately. Once the source
location has been renamed to the destination any future commands
applied to the source location will create new files there and not
-impact the destination of the rename.
+affect the destination of the rename.
Note that a `filerename` is the same as a `filecopy` followed by a
`filedelete` of the source location. There is a slight performance
@@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
to be required).
~~~~~~~~~~
Causes fast-import to print the entire `progress` line unmodified to
its standard output channel (file descriptor 1) when the command is
-processed from the input stream. The command otherwise has no impact
+processed from the input stream. The command otherwise has no effect
on the current import, or on any of fast-import's internal state.
....
@@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
~~~~~~~~~~
Causes fast-import to print the SHA-1 corresponding to a mark to
stdout or to the file descriptor previously arranged with the
-`--cat-blob-fd` argument. The command otherwise has no impact on the
+`--cat-blob-fd` argument. The command otherwise has no effect on the
current import; its purpose is to retrieve SHA-1s that later commits
might want to refer to in their commit messages.
@@ -1050,7 +1050,7 @@ this output safely.
~~~~~~~~~~
Causes fast-import to print a blob to a file descriptor previously
arranged with the `--cat-blob-fd` argument. The command otherwise
-has no impact on the current import; its main purpose is to
+has no effect on the current import; its main purpose is to
retrieve blobs that may be in fast-import's memory but not
accessible from the target repository.
@@ -1366,7 +1366,7 @@ code considerably.
The branch LRU builtin to fast-import tends to behave very well, and the
cost of activating an inactive branch is so low that bouncing around
-between branches has virtually no impact on import performance.
+between branches has virtually no effect on import performance.
Handling Renames
~~~~~~~~~~~~~~~~
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 9067c2079e..01cf3b3d16 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
If left to accumulate, these stale references might make performance
worse on big and busy repos that have a lot of branch churn, and
e.g. make the output of commands like `git branch -a --contains
-<commit>` needlessly verbose, as well as impacting anything else
+<commit>` needlessly verbose, as well as affecting anything else
that'll work with the complete set of known references.
These remote-tracking references can be deleted as a one-off with
diff --git a/Documentation/technical/hash-function-transition.txt
b/Documentation/technical/hash-function-transition.txt
index 7c1630bf83..f4296faffc 100644
--- a/Documentation/technical/hash-function-transition.txt
+++ b/Documentation/technical/hash-function-transition.txt
@@ -42,7 +42,7 @@ mitigations.
If SHA-1 and its variants were to be truly broken, Git's hash function
could not be considered cryptographically secure any more. This would
-impact the communication of hash values because we could not trust
+affect the communication of hash values because we could not trust
that a given hash value represented the known good version of content
that the speaker intended.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index fd480b8645..33c60c49d7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
-state without impacting any branches by performing another switch.
+state without affecting any branches by performing another switch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command again. Example:
@@ -1189,7 +1189,7 @@ their histories forked. The work tree is
overwritten by the result of
the merge when this combining is done cleanly, or overwritten by a
half-merged results when this combining results in conflicts.
Therefore, if you have uncommitted changes touching the same files as
-the ones impacted by the merge, Git will refuse to proceed. Most of
+the ones affected by the merge, Git will refuse to proceed. Most of
the time, you will want to commit your changes before you can merge,
and if you don't, then linkgit:git-stash[1] can take these changes
away while you're doing the merge, and reapply them afterwards.
diff --git a/advice.c b/advice.c
index 164742305f..9cbbb824a9 100644
--- a/advice.c
+++ b/advice.c
@@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
"\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/builtin/fast-import.c b/builtin/fast-import.c
index 3afa81cf9a..24f362d2f4 100644
--- a/builtin/fast-import.c
+++ b/builtin/fast-import.c
@@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
const char *prefix)
* We don't parse most options until after we've seen the set of
* "feature" lines at the start of the stream (which allows the command
* line to override stream data). But we must do an early parse of any
- * command-line options that impact how we interpret the feature lines.
+ * command-line options that affect how we interpret the feature lines.
*/
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 525c2d8552..749bbca241 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
/*
* Mark ourselves as active and see if the next step causes
* us to cycle to another active object. It's important to do
- * this _before_ we loop, because it impacts where we make the
+ * this _before_ we loop, because it affects where we make the
* cut, and thus how our total_depth counter works.
* E.g., We may see a partial loop like:
*
diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
index f0e80bd7f0..92979ec770 100644
--- a/contrib/coccinelle/README
+++ b/contrib/coccinelle/README
@@ -40,4 +40,4 @@ There are two types of semantic patches:
are ignored for checks, and can be applied using 'make coccicheck-pending'.
This allows to expose plans of pending large scale refactorings without
- impacting the bad pattern checks.
+ affecting the bad pattern checks.
diff --git a/dir.c b/dir.c
index 3474e67e8f..235e26a90e 100644
--- a/dir.c
+++ b/dir.c
@@ -2144,7 +2144,7 @@ static enum path_treatment
treat_path_fast(struct dir_struct *dir,
/*
* We get path_recurse in the first run when
* directory_exists_in_index() returns index_nonexistent. We
- * are sure that new changes in the index does not impact the
+ * are sure that new changes in the index does not affect the
* outcome. Return now.
*/
return path_recurse;
diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
index d0e0e019ea..1fcb98443c 100755
--- a/t/perf/p5550-fetch-tags.sh
+++ b/t/perf/p5550-fetch-tags.sh
@@ -8,7 +8,7 @@ follows.
The parent repository has a large number of tags which are disconnected from
the rest of history. That makes them candidates for tag-following, but we never
-actually grab them (and thus they will impact each subsequent fetch).
+actually grab them (and thus they will affect each subsequent fetch).
The child repository is a clone of parent, without the tags, and is at least
one commit behind the parent (meaning that we will fetch one object and then
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index a594b4aa7d..95daba4000 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
# test standard ignores
# First make sure that the presence of a file in the working tree
-# does not impact results, but that the presence of a file in the
+# does not affect results, but that the presence of a file in the
# index does unless the --no-index option is used.
for subdir in '' 'a/'
diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
index f028fd1418..a9348f655a 100755
--- a/t/t0303-credential-external.sh
+++ b/t/t0303-credential-external.sh
@@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
# clean before the test in case there is cruft left
-# over from a previous run that would impact results
+# over from a previous run that would affect results
helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
helper_test "$GIT_TEST_CREDENTIAL_HELPER"
diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
index bc46713a43..568c258c5a 100755
--- a/t/t2020-checkout-detach.sh
+++ b/t/t2020-checkout-detach.sh
@@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
no SHA-1 ellipsis when not as
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
- state without impacting any branches by switching back to a branch.
+ state without affecting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
@@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
print SHA-1 ellipsis when asked
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
- state without impacting any branches by switching back to a branch.
+ state without affecting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 6cca8b84a6..97365a7786 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -109,7 +109,7 @@ test_expect_success setup '
git checkout -f master &&
# Same merge as master, but with parents reversed. Hide it in a
- # pseudo-ref to avoid impacting tests with --all.
+ # pseudo-ref to avoid affecting tests with --all.
commit=$(echo reverse |
git commit-tree -p master^2 -p master^1 master^{tree}) &&
git update-ref REVERSE $commit &&
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 7204799a0b..33a6efce2f 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
# Pull the size and date of each entry in a tarfile using the system tar.
#
# We'll pull out only the year from the date; that avoids any question of
-# timezones impacting the result (as long as we keep our test times away from a
+# timezones affecting the result (as long as we keep our test times away from a
# year boundary; our reference times are all in August).
#
# The output of tar_info is expected to be "<size> <year>", both in decimal. It
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 6348e8d733..ff65f86f50 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
}
# Like "env FOO=BAR some-program", but run inside a subshell, which means
-# it also works for shell functions (though those functions cannot impact
+# it also works for shell functions (though those functions cannot affect
# the environment outside of the test_env invocation).
test_env () {
(
--
2.17.1
On Tue, 6 Apr 2021 at 19:06, Varun Varada <varuncvarada@gmail.com> wrote:
>
> On Tue, 6 Apr 2021 at 18:01, Jeff King <peff@peff.net> wrote:
> >
> > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
> >
> > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > problem the word "impact" in itself is not "jargon".
> > >
> > > The word means "to have a strong or marked effect on" (v.) and "a
> > > strong or market influence" (n.) when used figuratively; it is not
> > > synonymous with "affect" and "effect", respectively, as shown even by
> > > all of the entries you've cited. Using it as such is the incorrect
> > > part, so those are the instances I've changed in the diff.
> >
> > Er, is that true? From Michal's definitions:
> >
> > > > From The Collaborative International Dictionary of English v.0.48 :
> > > [...]
> > > > 2. To affect or influence, especially in a significant or
> >
> > It literally uses "affect" to define it. The "especially significant"
> > does not apply to many, but I don't think that makes it necessarily
> > wrong to use impact to mean "affect".
>
> I was drawing attention to the "especially significant" bit and the
> like being there in all the entries. I'm not sure about these
> dictionaries, but the definition is hyperbolic / violent / shocking in
> every reputable dictionary out there: the Oxford English Dictionary,
> Merriam-Webster, and Collins.
>
> >
> > Likewise:
> >
> > > > From WordNet (r) 3.0 (2006) :
> > > [...]
> > > > v 1: press or wedge together; pack together
> > > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > > affect, impact, bear upon, bear on, touch on,
> > > > touch]
> >
> > That is likewise listing "impact" and "affect" as synonyms.
> >
> > I do agree the word is over-used in some forms of writing, but I don't
> > find anything at all confusing or wrong about the uses that you changed
> > in your patch. I am a native speaker of English. I'm open to the
> > argument that non-native speakers may be more confused by the word. But
> > this seems like mostly a style preference thing, and I'd generally
> > prefer to leave the contributions and style of the original writers
> > intact unless there is a good reason not to.
>
> I am a native English speaker as well, and there were multiple places
> where I had to think twice about what the sentences mean. I agree with
> your sentiment about leaving stylistic preferences intact, but this is
> actually a semantic one. And given that there is a perfectly good
> alternative that doesn't have this confusion / jargon status, I wanted
> to make the change to improve it, especially where it says that in the
> output of the git command (`git checkout` when in detached HEAD mode).
>
> >
> > Such changes are doubly unwanted in cases like this:
> >
> > > --- a/compat/nedmalloc/malloc.c.h
> > > +++ b/compat/nedmalloc/malloc.c.h
> > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > > #endif /* (FOOTERS && !INSECURE) */
> > >
> > >
> > > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > > #if !INSECURE
> > > #if defined(__GNUC__) && __GNUC__ >= 3
> > > #define RTCHECK(e) __builtin_expect(e, 1)
> >
> > where the text is imported from another project, and we'd prefer to stay
> > as close to their version as possible (e.g., to avoid unnecessary
> > conflicts when pulling in new versions).
>
> That's fair; I wasn't aware that this was being pulled directly from
> another project. I can change this back.
>
> >
> > Also, this one should be "effect" anyway, as it is a noun.
>
> This seems to have slipped through, as I used a text search tool.
>
> >
> > -Peff
^ permalink raw reply related [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-28 0:39 ` Varun Varada
@ 2021-04-28 8:58 ` Michal Suchánek
2021-04-28 18:15 ` Varun Varada
2021-05-12 2:34 ` Felipe Contreras
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-04-28 8:58 UTC (permalink / raw)
To: Varun Varada; +Cc: Jeff King, git
On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:
> Here's the updated diff:
As already said multiple general purpose dictionaries recognize '(have)
strong effect' as the meaning of 'impact', in some cases even the most
common meaning.
In case you have some issue with the word 'jargon' Merriam-Webster gives
this definition:
1: the technical terminology or characteristic idiom of a special activity or group
2: obscure and often pretentious language marked by circumlocutions and long words
3a: confused unintelligible language
b: a strange, outlandish, or barbarous language or dialect
c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech
which the word 'impact' does not fulfill.
Further, you would rarely discuss and document an effect that is
negligible so in vast majority of cases '(have) strong effect' (ie
'impact') is synonymous to 'affect' and 'affect', respectively.
If you can pick out a few places where the use is specifically confusing
then please pick out those. Wholesale replacement of one word with
another synonym is not desired. It creates useless churn.
You could make a case that 'impact' is significantly less frequent word
compared to effect/affect and thus makes the text harder to understand
for non-native speakers. However, that's not the point you brought up,
and even then it is very weak point to make, especially without any
actual source for the frequency data. You could also counter that all of
these are common loanwords in many languages and are thus easy to
understand to non-native speakers anyway.
Thanks
Michal
>
> Documentation/MyFirstContribution.txt | 2 +-
> Documentation/MyFirstObjectWalk.txt | 2 +-
> Documentation/config/pack.txt | 2 +-
> Documentation/git-fast-import.txt | 14 +++++++-------
> Documentation/git-fetch.txt | 2 +-
> .../technical/hash-function-transition.txt | 2 +-
> Documentation/user-manual.txt | 4 ++--
> advice.c | 2 +-
> builtin/fast-import.c | 2 +-
> builtin/pack-objects.c | 2 +-
> contrib/coccinelle/README | 2 +-
> dir.c | 2 +-
> t/perf/p5550-fetch-tags.sh | 2 +-
> t/t0008-ignores.sh | 2 +-
> t/t0303-credential-external.sh | 2 +-
> t/t2020-checkout-detach.sh | 4 ++--
> t/t4013-diff-various.sh | 2 +-
> t/t5000-tar-tree.sh | 2 +-
> t/test-lib-functions.sh | 2 +-
> 19 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/Documentation/MyFirstContribution.txt
> b/Documentation/MyFirstContribution.txt
> index af0a9da62e..8372a7e59e 100644
> --- a/Documentation/MyFirstContribution.txt
> +++ b/Documentation/MyFirstContribution.txt
> @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> how to show it in the general
> command list shown by `git help git` or `git help -a`, which is generated from
> `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> line above it in alphabetical order. Now, we can add some attributes about the
> -command which impacts where it shows up in the aforementioned help
> commands. The
> +command which affects where it shows up in the aforementioned help
> commands. The
> top of `command-list.txt` shares some information about what each attribute
> means; in those help pages, the commands are sorted according to these
> attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> diff --git a/Documentation/MyFirstObjectWalk.txt
> b/Documentation/MyFirstObjectWalk.txt
> index 2d10eea7a9..fd5bb8fb7d 100644
> --- a/Documentation/MyFirstObjectWalk.txt
> +++ b/Documentation/MyFirstObjectWalk.txt
> @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> By running your walk with and without the filter, you should find
> that the total
> object count in each case is identical. You can also time each invocation of
> the `walken` subcommand, with and without `omitted` being passed in, to confirm
> -to yourself the runtime impact of tracking all omitted objects.
> +to yourself the runtime effect of tracking all omitted objects.
>
> === Changing the Order
>
> diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> index 3da4ea98e2..00fcc9d7c7 100644
> --- a/Documentation/config/pack.txt
> +++ b/Documentation/config/pack.txt
> @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> This cache is used to speed up the writing object phase by not
> having to recompute the final delta result once the best match
> for all objects is found. Repacking large repositories on machines
> - which are tight with memory might be badly impacted by this though,
> + which are tight with memory might be badly affected by this though,
> especially if this cache pushes the system into swapping.
> A value of 0 means no limit. The smallest size of 1 byte may be
> used to virtually disable this cache. Defaults to 256 MiB.
> diff --git a/Documentation/git-fast-import.txt
> b/Documentation/git-fast-import.txt
> index 39cfa05b28..c6d8e4e1d7 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -58,7 +58,7 @@ OPTIONS
> allowing fast-import to access the filesystem outside of the
> repository). These options are disabled by default, but can be
> allowed by providing this option on the command line. This
> - currently impacts only the `export-marks`, `import-marks`, and
> + currently affects only the `export-marks`, `import-marks`, and
> `import-marks-if-exists` feature commands.
> +
> Only enable this option if you trust the program generating the
> @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
>
> A `filecopy` command takes effect immediately. Once the source
> location has been copied to the destination any future commands
> -applied to the source location will not impact the destination of
> +applied to the source location will not affect the destination of
> the copy.
>
> `filerename`
> @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> A `filerename` command takes effect immediately. Once the source
> location has been renamed to the destination any future commands
> applied to the source location will create new files there and not
> -impact the destination of the rename.
> +affect the destination of the rename.
>
> Note that a `filerename` is the same as a `filecopy` followed by a
> `filedelete` of the source location. There is a slight performance
> @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> to be required).
> ~~~~~~~~~~
> Causes fast-import to print the entire `progress` line unmodified to
> its standard output channel (file descriptor 1) when the command is
> -processed from the input stream. The command otherwise has no impact
> +processed from the input stream. The command otherwise has no effect
> on the current import, or on any of fast-import's internal state.
>
> ....
> @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> ~~~~~~~~~~
> Causes fast-import to print the SHA-1 corresponding to a mark to
> stdout or to the file descriptor previously arranged with the
> -`--cat-blob-fd` argument. The command otherwise has no impact on the
> +`--cat-blob-fd` argument. The command otherwise has no effect on the
> current import; its purpose is to retrieve SHA-1s that later commits
> might want to refer to in their commit messages.
>
> @@ -1050,7 +1050,7 @@ this output safely.
> ~~~~~~~~~~
> Causes fast-import to print a blob to a file descriptor previously
> arranged with the `--cat-blob-fd` argument. The command otherwise
> -has no impact on the current import; its main purpose is to
> +has no effect on the current import; its main purpose is to
> retrieve blobs that may be in fast-import's memory but not
> accessible from the target repository.
>
> @@ -1366,7 +1366,7 @@ code considerably.
>
> The branch LRU builtin to fast-import tends to behave very well, and the
> cost of activating an inactive branch is so low that bouncing around
> -between branches has virtually no impact on import performance.
> +between branches has virtually no effect on import performance.
>
> Handling Renames
> ~~~~~~~~~~~~~~~~
> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> index 9067c2079e..01cf3b3d16 100644
> --- a/Documentation/git-fetch.txt
> +++ b/Documentation/git-fetch.txt
> @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> If left to accumulate, these stale references might make performance
> worse on big and busy repos that have a lot of branch churn, and
> e.g. make the output of commands like `git branch -a --contains
> -<commit>` needlessly verbose, as well as impacting anything else
> +<commit>` needlessly verbose, as well as affecting anything else
> that'll work with the complete set of known references.
>
> These remote-tracking references can be deleted as a one-off with
> diff --git a/Documentation/technical/hash-function-transition.txt
> b/Documentation/technical/hash-function-transition.txt
> index 7c1630bf83..f4296faffc 100644
> --- a/Documentation/technical/hash-function-transition.txt
> +++ b/Documentation/technical/hash-function-transition.txt
> @@ -42,7 +42,7 @@ mitigations.
>
> If SHA-1 and its variants were to be truly broken, Git's hash function
> could not be considered cryptographically secure any more. This would
> -impact the communication of hash values because we could not trust
> +affect the communication of hash values because we could not trust
> that a given hash value represented the known good version of content
> that the speaker intended.
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index fd480b8645..33c60c49d7 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> -state without impacting any branches by performing another switch.
> +state without affecting any branches by performing another switch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command again. Example:
> @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> overwritten by the result of
> the merge when this combining is done cleanly, or overwritten by a
> half-merged results when this combining results in conflicts.
> Therefore, if you have uncommitted changes touching the same files as
> -the ones impacted by the merge, Git will refuse to proceed. Most of
> +the ones affected by the merge, Git will refuse to proceed. Most of
> the time, you will want to commit your changes before you can merge,
> and if you don't, then linkgit:git-stash[1] can take these changes
> away while you're doing the merge, and reapply them afterwards.
> diff --git a/advice.c b/advice.c
> index 164742305f..9cbbb824a9 100644
> --- a/advice.c
> +++ b/advice.c
> @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> "\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/builtin/fast-import.c b/builtin/fast-import.c
> index 3afa81cf9a..24f362d2f4 100644
> --- a/builtin/fast-import.c
> +++ b/builtin/fast-import.c
> @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> const char *prefix)
> * We don't parse most options until after we've seen the set of
> * "feature" lines at the start of the stream (which allows the command
> * line to override stream data). But we must do an early parse of any
> - * command-line options that impact how we interpret the feature lines.
> + * command-line options that affect how we interpret the feature lines.
> */
> for (i = 1; i < argc; i++) {
> const char *arg = argv[i];
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index 525c2d8552..749bbca241 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> /*
> * Mark ourselves as active and see if the next step causes
> * us to cycle to another active object. It's important to do
> - * this _before_ we loop, because it impacts where we make the
> + * this _before_ we loop, because it affects where we make the
> * cut, and thus how our total_depth counter works.
> * E.g., We may see a partial loop like:
> *
> diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> index f0e80bd7f0..92979ec770 100644
> --- a/contrib/coccinelle/README
> +++ b/contrib/coccinelle/README
> @@ -40,4 +40,4 @@ There are two types of semantic patches:
> are ignored for checks, and can be applied using 'make coccicheck-pending'.
>
> This allows to expose plans of pending large scale refactorings without
> - impacting the bad pattern checks.
> + affecting the bad pattern checks.
> diff --git a/dir.c b/dir.c
> index 3474e67e8f..235e26a90e 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -2144,7 +2144,7 @@ static enum path_treatment
> treat_path_fast(struct dir_struct *dir,
> /*
> * We get path_recurse in the first run when
> * directory_exists_in_index() returns index_nonexistent. We
> - * are sure that new changes in the index does not impact the
> + * are sure that new changes in the index does not affect the
> * outcome. Return now.
> */
> return path_recurse;
> diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> index d0e0e019ea..1fcb98443c 100755
> --- a/t/perf/p5550-fetch-tags.sh
> +++ b/t/perf/p5550-fetch-tags.sh
> @@ -8,7 +8,7 @@ follows.
>
> The parent repository has a large number of tags which are disconnected from
> the rest of history. That makes them candidates for tag-following, but we never
> -actually grab them (and thus they will impact each subsequent fetch).
> +actually grab them (and thus they will affect each subsequent fetch).
>
> The child repository is a clone of parent, without the tags, and is at least
> one commit behind the parent (meaning that we will fetch one object and then
> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> index a594b4aa7d..95daba4000 100755
> --- a/t/t0008-ignores.sh
> +++ b/t/t0008-ignores.sh
> @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> # test standard ignores
>
> # First make sure that the presence of a file in the working tree
> -# does not impact results, but that the presence of a file in the
> +# does not affect results, but that the presence of a file in the
> # index does unless the --no-index option is used.
>
> for subdir in '' 'a/'
> diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> index f028fd1418..a9348f655a 100755
> --- a/t/t0303-credential-external.sh
> +++ b/t/t0303-credential-external.sh
> @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
>
> # clean before the test in case there is cruft left
> -# over from a previous run that would impact results
> +# over from a previous run that would affect results
> helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
>
> helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> index bc46713a43..568c258c5a 100755
> --- a/t/t2020-checkout-detach.sh
> +++ b/t/t2020-checkout-detach.sh
> @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> no SHA-1 ellipsis when not as
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> - state without impacting any branches by switching back to a branch.
> + state without affecting any branches by switching back to a branch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command. Example:
> @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> print SHA-1 ellipsis when asked
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> - state without impacting any branches by switching back to a branch.
> + state without affecting any branches by switching back to a branch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command. Example:
> diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> index 6cca8b84a6..97365a7786 100755
> --- a/t/t4013-diff-various.sh
> +++ b/t/t4013-diff-various.sh
> @@ -109,7 +109,7 @@ test_expect_success setup '
> git checkout -f master &&
>
> # Same merge as master, but with parents reversed. Hide it in a
> - # pseudo-ref to avoid impacting tests with --all.
> + # pseudo-ref to avoid affecting tests with --all.
> commit=$(echo reverse |
> git commit-tree -p master^2 -p master^1 master^{tree}) &&
> git update-ref REVERSE $commit &&
> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> index 7204799a0b..33a6efce2f 100755
> --- a/t/t5000-tar-tree.sh
> +++ b/t/t5000-tar-tree.sh
> @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> # Pull the size and date of each entry in a tarfile using the system tar.
> #
> # We'll pull out only the year from the date; that avoids any question of
> -# timezones impacting the result (as long as we keep our test times away from a
> +# timezones affecting the result (as long as we keep our test times away from a
> # year boundary; our reference times are all in August).
> #
> # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index 6348e8d733..ff65f86f50 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> }
>
> # Like "env FOO=BAR some-program", but run inside a subshell, which means
> -# it also works for shell functions (though those functions cannot impact
> +# it also works for shell functions (though those functions cannot affect
> # the environment outside of the test_env invocation).
> test_env () {
> (
> --
> 2.17.1
>
> On Tue, 6 Apr 2021 at 19:06, Varun Varada <varuncvarada@gmail.com> wrote:
> >
> > On Tue, 6 Apr 2021 at 18:01, Jeff King <peff@peff.net> wrote:
> > >
> > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
> > >
> > > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > > problem the word "impact" in itself is not "jargon".
> > > >
> > > > The word means "to have a strong or marked effect on" (v.) and "a
> > > > strong or market influence" (n.) when used figuratively; it is not
> > > > synonymous with "affect" and "effect", respectively, as shown even by
> > > > all of the entries you've cited. Using it as such is the incorrect
> > > > part, so those are the instances I've changed in the diff.
> > >
> > > Er, is that true? From Michal's definitions:
> > >
> > > > > From The Collaborative International Dictionary of English v.0.48 :
> > > > [...]
> > > > > 2. To affect or influence, especially in a significant or
> > >
> > > It literally uses "affect" to define it. The "especially significant"
> > > does not apply to many, but I don't think that makes it necessarily
> > > wrong to use impact to mean "affect".
> >
> > I was drawing attention to the "especially significant" bit and the
> > like being there in all the entries. I'm not sure about these
> > dictionaries, but the definition is hyperbolic / violent / shocking in
> > every reputable dictionary out there: the Oxford English Dictionary,
> > Merriam-Webster, and Collins.
> >
> > >
> > > Likewise:
> > >
> > > > > From WordNet (r) 3.0 (2006) :
> > > > [...]
> > > > > v 1: press or wedge together; pack together
> > > > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > > > affect, impact, bear upon, bear on, touch on,
> > > > > touch]
> > >
> > > That is likewise listing "impact" and "affect" as synonyms.
> > >
> > > I do agree the word is over-used in some forms of writing, but I don't
> > > find anything at all confusing or wrong about the uses that you changed
> > > in your patch. I am a native speaker of English. I'm open to the
> > > argument that non-native speakers may be more confused by the word. But
> > > this seems like mostly a style preference thing, and I'd generally
> > > prefer to leave the contributions and style of the original writers
> > > intact unless there is a good reason not to.
> >
> > I am a native English speaker as well, and there were multiple places
> > where I had to think twice about what the sentences mean. I agree with
> > your sentiment about leaving stylistic preferences intact, but this is
> > actually a semantic one. And given that there is a perfectly good
> > alternative that doesn't have this confusion / jargon status, I wanted
> > to make the change to improve it, especially where it says that in the
> > output of the git command (`git checkout` when in detached HEAD mode).
> >
> > >
> > > Such changes are doubly unwanted in cases like this:
> > >
> > > > --- a/compat/nedmalloc/malloc.c.h
> > > > +++ b/compat/nedmalloc/malloc.c.h
> > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > > > #endif /* (FOOTERS && !INSECURE) */
> > > >
> > > >
> > > > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > > > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > > > #if !INSECURE
> > > > #if defined(__GNUC__) && __GNUC__ >= 3
> > > > #define RTCHECK(e) __builtin_expect(e, 1)
> > >
> > > where the text is imported from another project, and we'd prefer to stay
> > > as close to their version as possible (e.g., to avoid unnecessary
> > > conflicts when pulling in new versions).
> >
> > That's fair; I wasn't aware that this was being pulled directly from
> > another project. I can change this back.
> >
> > >
> > > Also, this one should be "effect" anyway, as it is a noun.
> >
> > This seems to have slipped through, as I used a text search tool.
> >
> > >
> > > -Peff
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-28 8:58 ` Michal Suchánek
@ 2021-04-28 18:15 ` Varun Varada
2021-04-28 18:49 ` Michal Suchánek
2021-05-12 2:34 ` Felipe Contreras
1 sibling, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-04-28 18:15 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Jeff King, git
On Wed, 28 Apr 2021 at 03:58, Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:
> > Here's the updated diff:
>
> As already said multiple general purpose dictionaries recognize '(have)
> strong effect' as the meaning of 'impact', in some cases even the most
> common meaning.
There's no contention here. That's the meaning I've been referring to as well.
>
> In case you have some issue with the word 'jargon' Merriam-Webster gives
> this definition:
>
> 1: the technical terminology or characteristic idiom of a special activity or group
> 2: obscure and often pretentious language marked by circumlocutions and long words
> 3a: confused unintelligible language
> b: a strange, outlandish, or barbarous language or dialect
> c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech
>
> which the word 'impact' does not fulfill.
>
> Further, you would rarely discuss and document an effect that is
> negligible so in vast majority of cases '(have) strong effect' (ie
> 'impact') is synonymous to 'affect' and 'affect', respectively.
This is not true, especially in technical contexts. "Affect" doesn't
mean "has a slight effect on", but simply "has an effect on". This
suffices in most cases. In cases where one would like to highlight the
overwhelming/awesome/debilitating/marked/strong effect that something
has, "impact" can be used. To say that every effect is overwhelming or
strong is jargon.
>
> If you can pick out a few places where the use is specifically confusing
> then please pick out those. Wholesale replacement of one word with
> another synonym is not desired. It creates useless churn.
I've actually not done a wholesale replacement blindly; the ones I
replaced are the places where I couldn't find any case where it is
referring to a "strong/marked effect". This is especially true in the
negative constructions. If you could help me find places where you
think the intended meaning is indeed "a strong/marked effect", I can
remove those from the changes.
>
> You could make a case that 'impact' is significantly less frequent word
> compared to effect/affect and thus makes the text harder to understand
> for non-native speakers. However, that's not the point you brought up,
> and even then it is very weak point to make, especially without any
> actual source for the frequency data. You could also counter that all of
> these are common loanwords in many languages and are thus easy to
> understand to non-native speakers anyway.
>
> Thanks
>
> Michal
> >
> > Documentation/MyFirstContribution.txt | 2 +-
> > Documentation/MyFirstObjectWalk.txt | 2 +-
> > Documentation/config/pack.txt | 2 +-
> > Documentation/git-fast-import.txt | 14 +++++++-------
> > Documentation/git-fetch.txt | 2 +-
> > .../technical/hash-function-transition.txt | 2 +-
> > Documentation/user-manual.txt | 4 ++--
> > advice.c | 2 +-
> > builtin/fast-import.c | 2 +-
> > builtin/pack-objects.c | 2 +-
> > contrib/coccinelle/README | 2 +-
> > dir.c | 2 +-
> > t/perf/p5550-fetch-tags.sh | 2 +-
> > t/t0008-ignores.sh | 2 +-
> > t/t0303-credential-external.sh | 2 +-
> > t/t2020-checkout-detach.sh | 4 ++--
> > t/t4013-diff-various.sh | 2 +-
> > t/t5000-tar-tree.sh | 2 +-
> > t/test-lib-functions.sh | 2 +-
> > 19 files changed, 27 insertions(+), 27 deletions(-)
> >
> > diff --git a/Documentation/MyFirstContribution.txt
> > b/Documentation/MyFirstContribution.txt
> > index af0a9da62e..8372a7e59e 100644
> > --- a/Documentation/MyFirstContribution.txt
> > +++ b/Documentation/MyFirstContribution.txt
> > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> > how to show it in the general
> > command list shown by `git help git` or `git help -a`, which is generated from
> > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> > line above it in alphabetical order. Now, we can add some attributes about the
> > -command which impacts where it shows up in the aforementioned help
> > commands. The
> > +command which affects where it shows up in the aforementioned help
> > commands. The
> > top of `command-list.txt` shares some information about what each attribute
> > means; in those help pages, the commands are sorted according to these
> > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> > diff --git a/Documentation/MyFirstObjectWalk.txt
> > b/Documentation/MyFirstObjectWalk.txt
> > index 2d10eea7a9..fd5bb8fb7d 100644
> > --- a/Documentation/MyFirstObjectWalk.txt
> > +++ b/Documentation/MyFirstObjectWalk.txt
> > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> > By running your walk with and without the filter, you should find
> > that the total
> > object count in each case is identical. You can also time each invocation of
> > the `walken` subcommand, with and without `omitted` being passed in, to confirm
> > -to yourself the runtime impact of tracking all omitted objects.
> > +to yourself the runtime effect of tracking all omitted objects.
> >
> > === Changing the Order
> >
> > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> > index 3da4ea98e2..00fcc9d7c7 100644
> > --- a/Documentation/config/pack.txt
> > +++ b/Documentation/config/pack.txt
> > @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> > This cache is used to speed up the writing object phase by not
> > having to recompute the final delta result once the best match
> > for all objects is found. Repacking large repositories on machines
> > - which are tight with memory might be badly impacted by this though,
> > + which are tight with memory might be badly affected by this though,
> > especially if this cache pushes the system into swapping.
> > A value of 0 means no limit. The smallest size of 1 byte may be
> > used to virtually disable this cache. Defaults to 256 MiB.
> > diff --git a/Documentation/git-fast-import.txt
> > b/Documentation/git-fast-import.txt
> > index 39cfa05b28..c6d8e4e1d7 100644
> > --- a/Documentation/git-fast-import.txt
> > +++ b/Documentation/git-fast-import.txt
> > @@ -58,7 +58,7 @@ OPTIONS
> > allowing fast-import to access the filesystem outside of the
> > repository). These options are disabled by default, but can be
> > allowed by providing this option on the command line. This
> > - currently impacts only the `export-marks`, `import-marks`, and
> > + currently affects only the `export-marks`, `import-marks`, and
> > `import-marks-if-exists` feature commands.
> > +
> > Only enable this option if you trust the program generating the
> > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
> >
> > A `filecopy` command takes effect immediately. Once the source
> > location has been copied to the destination any future commands
> > -applied to the source location will not impact the destination of
> > +applied to the source location will not affect the destination of
> > the copy.
> >
> > `filerename`
> > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> > A `filerename` command takes effect immediately. Once the source
> > location has been renamed to the destination any future commands
> > applied to the source location will create new files there and not
> > -impact the destination of the rename.
> > +affect the destination of the rename.
> >
> > Note that a `filerename` is the same as a `filecopy` followed by a
> > `filedelete` of the source location. There is a slight performance
> > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> > to be required).
> > ~~~~~~~~~~
> > Causes fast-import to print the entire `progress` line unmodified to
> > its standard output channel (file descriptor 1) when the command is
> > -processed from the input stream. The command otherwise has no impact
> > +processed from the input stream. The command otherwise has no effect
> > on the current import, or on any of fast-import's internal state.
> >
> > ....
> > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> > ~~~~~~~~~~
> > Causes fast-import to print the SHA-1 corresponding to a mark to
> > stdout or to the file descriptor previously arranged with the
> > -`--cat-blob-fd` argument. The command otherwise has no impact on the
> > +`--cat-blob-fd` argument. The command otherwise has no effect on the
> > current import; its purpose is to retrieve SHA-1s that later commits
> > might want to refer to in their commit messages.
> >
> > @@ -1050,7 +1050,7 @@ this output safely.
> > ~~~~~~~~~~
> > Causes fast-import to print a blob to a file descriptor previously
> > arranged with the `--cat-blob-fd` argument. The command otherwise
> > -has no impact on the current import; its main purpose is to
> > +has no effect on the current import; its main purpose is to
> > retrieve blobs that may be in fast-import's memory but not
> > accessible from the target repository.
> >
> > @@ -1366,7 +1366,7 @@ code considerably.
> >
> > The branch LRU builtin to fast-import tends to behave very well, and the
> > cost of activating an inactive branch is so low that bouncing around
> > -between branches has virtually no impact on import performance.
> > +between branches has virtually no effect on import performance.
> >
> > Handling Renames
> > ~~~~~~~~~~~~~~~~
> > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> > index 9067c2079e..01cf3b3d16 100644
> > --- a/Documentation/git-fetch.txt
> > +++ b/Documentation/git-fetch.txt
> > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> > If left to accumulate, these stale references might make performance
> > worse on big and busy repos that have a lot of branch churn, and
> > e.g. make the output of commands like `git branch -a --contains
> > -<commit>` needlessly verbose, as well as impacting anything else
> > +<commit>` needlessly verbose, as well as affecting anything else
> > that'll work with the complete set of known references.
> >
> > These remote-tracking references can be deleted as a one-off with
> > diff --git a/Documentation/technical/hash-function-transition.txt
> > b/Documentation/technical/hash-function-transition.txt
> > index 7c1630bf83..f4296faffc 100644
> > --- a/Documentation/technical/hash-function-transition.txt
> > +++ b/Documentation/technical/hash-function-transition.txt
> > @@ -42,7 +42,7 @@ mitigations.
> >
> > If SHA-1 and its variants were to be truly broken, Git's hash function
> > could not be considered cryptographically secure any more. This would
> > -impact the communication of hash values because we could not trust
> > +affect the communication of hash values because we could not trust
> > that a given hash value represented the known good version of content
> > that the speaker intended.
> >
> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > index fd480b8645..33c60c49d7 100644
> > --- a/Documentation/user-manual.txt
> > +++ b/Documentation/user-manual.txt
> > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
> >
> > You are in 'detached HEAD' state. You can look around, make experimental
> > changes and commit them, and you can discard any commits you make in this
> > -state without impacting any branches by performing another switch.
> > +state without affecting any branches by performing another switch.
> >
> > If you want to create a new branch to retain commits you create, you may
> > do so (now or later) by using -c with the switch command again. Example:
> > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> > overwritten by the result of
> > the merge when this combining is done cleanly, or overwritten by a
> > half-merged results when this combining results in conflicts.
> > Therefore, if you have uncommitted changes touching the same files as
> > -the ones impacted by the merge, Git will refuse to proceed. Most of
> > +the ones affected by the merge, Git will refuse to proceed. Most of
> > the time, you will want to commit your changes before you can merge,
> > and if you don't, then linkgit:git-stash[1] can take these changes
> > away while you're doing the merge, and reapply them afterwards.
> > diff --git a/advice.c b/advice.c
> > index 164742305f..9cbbb824a9 100644
> > --- a/advice.c
> > +++ b/advice.c
> > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> > "\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/builtin/fast-import.c b/builtin/fast-import.c
> > index 3afa81cf9a..24f362d2f4 100644
> > --- a/builtin/fast-import.c
> > +++ b/builtin/fast-import.c
> > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> > const char *prefix)
> > * We don't parse most options until after we've seen the set of
> > * "feature" lines at the start of the stream (which allows the command
> > * line to override stream data). But we must do an early parse of any
> > - * command-line options that impact how we interpret the feature lines.
> > + * command-line options that affect how we interpret the feature lines.
> > */
> > for (i = 1; i < argc; i++) {
> > const char *arg = argv[i];
> > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> > index 525c2d8552..749bbca241 100644
> > --- a/builtin/pack-objects.c
> > +++ b/builtin/pack-objects.c
> > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> > /*
> > * Mark ourselves as active and see if the next step causes
> > * us to cycle to another active object. It's important to do
> > - * this _before_ we loop, because it impacts where we make the
> > + * this _before_ we loop, because it affects where we make the
> > * cut, and thus how our total_depth counter works.
> > * E.g., We may see a partial loop like:
> > *
> > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> > index f0e80bd7f0..92979ec770 100644
> > --- a/contrib/coccinelle/README
> > +++ b/contrib/coccinelle/README
> > @@ -40,4 +40,4 @@ There are two types of semantic patches:
> > are ignored for checks, and can be applied using 'make coccicheck-pending'.
> >
> > This allows to expose plans of pending large scale refactorings without
> > - impacting the bad pattern checks.
> > + affecting the bad pattern checks.
> > diff --git a/dir.c b/dir.c
> > index 3474e67e8f..235e26a90e 100644
> > --- a/dir.c
> > +++ b/dir.c
> > @@ -2144,7 +2144,7 @@ static enum path_treatment
> > treat_path_fast(struct dir_struct *dir,
> > /*
> > * We get path_recurse in the first run when
> > * directory_exists_in_index() returns index_nonexistent. We
> > - * are sure that new changes in the index does not impact the
> > + * are sure that new changes in the index does not affect the
> > * outcome. Return now.
> > */
> > return path_recurse;
> > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> > index d0e0e019ea..1fcb98443c 100755
> > --- a/t/perf/p5550-fetch-tags.sh
> > +++ b/t/perf/p5550-fetch-tags.sh
> > @@ -8,7 +8,7 @@ follows.
> >
> > The parent repository has a large number of tags which are disconnected from
> > the rest of history. That makes them candidates for tag-following, but we never
> > -actually grab them (and thus they will impact each subsequent fetch).
> > +actually grab them (and thus they will affect each subsequent fetch).
> >
> > The child repository is a clone of parent, without the tags, and is at least
> > one commit behind the parent (meaning that we will fetch one object and then
> > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> > index a594b4aa7d..95daba4000 100755
> > --- a/t/t0008-ignores.sh
> > +++ b/t/t0008-ignores.sh
> > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> > # test standard ignores
> >
> > # First make sure that the presence of a file in the working tree
> > -# does not impact results, but that the presence of a file in the
> > +# does not affect results, but that the presence of a file in the
> > # index does unless the --no-index option is used.
> >
> > for subdir in '' 'a/'
> > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> > index f028fd1418..a9348f655a 100755
> > --- a/t/t0303-credential-external.sh
> > +++ b/t/t0303-credential-external.sh
> > @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> > eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
> >
> > # clean before the test in case there is cruft left
> > -# over from a previous run that would impact results
> > +# over from a previous run that would affect results
> > helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
> >
> > helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> > index bc46713a43..568c258c5a 100755
> > --- a/t/t2020-checkout-detach.sh
> > +++ b/t/t2020-checkout-detach.sh
> > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> > no SHA-1 ellipsis when not as
> >
> > You are in 'detached HEAD' state. You can look around, make experimental
> > changes and commit them, and you can discard any commits you make in this
> > - state without impacting any branches by switching back to a branch.
> > + state without affecting any branches by switching back to a branch.
> >
> > If you want to create a new branch to retain commits you create, you may
> > do so (now or later) by using -c with the switch command. Example:
> > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> > print SHA-1 ellipsis when asked
> >
> > You are in 'detached HEAD' state. You can look around, make experimental
> > changes and commit them, and you can discard any commits you make in this
> > - state without impacting any branches by switching back to a branch.
> > + state without affecting any branches by switching back to a branch.
> >
> > If you want to create a new branch to retain commits you create, you may
> > do so (now or later) by using -c with the switch command. Example:
> > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> > index 6cca8b84a6..97365a7786 100755
> > --- a/t/t4013-diff-various.sh
> > +++ b/t/t4013-diff-various.sh
> > @@ -109,7 +109,7 @@ test_expect_success setup '
> > git checkout -f master &&
> >
> > # Same merge as master, but with parents reversed. Hide it in a
> > - # pseudo-ref to avoid impacting tests with --all.
> > + # pseudo-ref to avoid affecting tests with --all.
> > commit=$(echo reverse |
> > git commit-tree -p master^2 -p master^1 master^{tree}) &&
> > git update-ref REVERSE $commit &&
> > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> > index 7204799a0b..33a6efce2f 100755
> > --- a/t/t5000-tar-tree.sh
> > +++ b/t/t5000-tar-tree.sh
> > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> > # Pull the size and date of each entry in a tarfile using the system tar.
> > #
> > # We'll pull out only the year from the date; that avoids any question of
> > -# timezones impacting the result (as long as we keep our test times away from a
> > +# timezones affecting the result (as long as we keep our test times away from a
> > # year boundary; our reference times are all in August).
> > #
> > # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> > index 6348e8d733..ff65f86f50 100644
> > --- a/t/test-lib-functions.sh
> > +++ b/t/test-lib-functions.sh
> > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> > }
> >
> > # Like "env FOO=BAR some-program", but run inside a subshell, which means
> > -# it also works for shell functions (though those functions cannot impact
> > +# it also works for shell functions (though those functions cannot affect
> > # the environment outside of the test_env invocation).
> > test_env () {
> > (
> > --
> > 2.17.1
> >
> > On Tue, 6 Apr 2021 at 19:06, Varun Varada <varuncvarada@gmail.com> wrote:
> > >
> > > On Tue, 6 Apr 2021 at 18:01, Jeff King <peff@peff.net> wrote:
> > > >
> > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
> > > >
> > > > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > > > problem the word "impact" in itself is not "jargon".
> > > > >
> > > > > The word means "to have a strong or marked effect on" (v.) and "a
> > > > > strong or market influence" (n.) when used figuratively; it is not
> > > > > synonymous with "affect" and "effect", respectively, as shown even by
> > > > > all of the entries you've cited. Using it as such is the incorrect
> > > > > part, so those are the instances I've changed in the diff.
> > > >
> > > > Er, is that true? From Michal's definitions:
> > > >
> > > > > > From The Collaborative International Dictionary of English v.0.48 :
> > > > > [...]
> > > > > > 2. To affect or influence, especially in a significant or
> > > >
> > > > It literally uses "affect" to define it. The "especially significant"
> > > > does not apply to many, but I don't think that makes it necessarily
> > > > wrong to use impact to mean "affect".
> > >
> > > I was drawing attention to the "especially significant" bit and the
> > > like being there in all the entries. I'm not sure about these
> > > dictionaries, but the definition is hyperbolic / violent / shocking in
> > > every reputable dictionary out there: the Oxford English Dictionary,
> > > Merriam-Webster, and Collins.
> > >
> > > >
> > > > Likewise:
> > > >
> > > > > > From WordNet (r) 3.0 (2006) :
> > > > > [...]
> > > > > > v 1: press or wedge together; pack together
> > > > > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > > > > affect, impact, bear upon, bear on, touch on,
> > > > > > touch]
> > > >
> > > > That is likewise listing "impact" and "affect" as synonyms.
> > > >
> > > > I do agree the word is over-used in some forms of writing, but I don't
> > > > find anything at all confusing or wrong about the uses that you changed
> > > > in your patch. I am a native speaker of English. I'm open to the
> > > > argument that non-native speakers may be more confused by the word. But
> > > > this seems like mostly a style preference thing, and I'd generally
> > > > prefer to leave the contributions and style of the original writers
> > > > intact unless there is a good reason not to.
> > >
> > > I am a native English speaker as well, and there were multiple places
> > > where I had to think twice about what the sentences mean. I agree with
> > > your sentiment about leaving stylistic preferences intact, but this is
> > > actually a semantic one. And given that there is a perfectly good
> > > alternative that doesn't have this confusion / jargon status, I wanted
> > > to make the change to improve it, especially where it says that in the
> > > output of the git command (`git checkout` when in detached HEAD mode).
> > >
> > > >
> > > > Such changes are doubly unwanted in cases like this:
> > > >
> > > > > --- a/compat/nedmalloc/malloc.c.h
> > > > > +++ b/compat/nedmalloc/malloc.c.h
> > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > > > > #endif /* (FOOTERS && !INSECURE) */
> > > > >
> > > > >
> > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > > > > #if !INSECURE
> > > > > #if defined(__GNUC__) && __GNUC__ >= 3
> > > > > #define RTCHECK(e) __builtin_expect(e, 1)
> > > >
> > > > where the text is imported from another project, and we'd prefer to stay
> > > > as close to their version as possible (e.g., to avoid unnecessary
> > > > conflicts when pulling in new versions).
> > >
> > > That's fair; I wasn't aware that this was being pulled directly from
> > > another project. I can change this back.
> > >
> > > >
> > > > Also, this one should be "effect" anyway, as it is a noun.
> > >
> > > This seems to have slipped through, as I used a text search tool.
> > >
> > > >
> > > > -Peff
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-28 18:15 ` Varun Varada
@ 2021-04-28 18:49 ` Michal Suchánek
2021-04-30 1:51 ` Varun Varada
2021-05-12 2:38 ` Felipe Contreras
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-04-28 18:49 UTC (permalink / raw)
To: Varun Varada; +Cc: Jeff King, git
On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:
> On Wed, 28 Apr 2021 at 03:58, Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:
> > > Here's the updated diff:
> >
> > As already said multiple general purpose dictionaries recognize '(have)
> > strong effect' as the meaning of 'impact', in some cases even the most
> > common meaning.
>
> There's no contention here. That's the meaning I've been referring to as well.
>
> >
> > In case you have some issue with the word 'jargon' Merriam-Webster gives
> > this definition:
> >
> > 1: the technical terminology or characteristic idiom of a special activity or group
> > 2: obscure and often pretentious language marked by circumlocutions and long words
> > 3a: confused unintelligible language
> > b: a strange, outlandish, or barbarous language or dialect
> > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech
> >
> > which the word 'impact' does not fulfill.
> >
> > Further, you would rarely discuss and document an effect that is
> > negligible so in vast majority of cases '(have) strong effect' (ie
> > 'impact') is synonymous to 'affect' and 'affect', respectively.
>
> This is not true, especially in technical contexts. "Affect" doesn't
> mean "has a slight effect on", but simply "has an effect on". This
> suffices in most cases. In cases where one would like to highlight the
> overwhelming/awesome/debilitating/marked/strong effect that something
> has, "impact" can be used. To say that every effect is overwhelming or
> strong is jargon.
>
> >
> > If you can pick out a few places where the use is specifically confusing
> > then please pick out those. Wholesale replacement of one word with
> > another synonym is not desired. It creates useless churn.
>
> I've actually not done a wholesale replacement blindly; the ones I
> replaced are the places where I couldn't find any case where it is
> referring to a "strong/marked effect". This is especially true in the
> negative constructions. If you could help me find places where you
> think the intended meaning is indeed "a strong/marked effect", I can
> remove those from the changes.
As already pointed out before the mere fact that the author of the text
bothered to document the effect ipmlies that the effect is strong/marked
unless stated otherwise. At any rate 'strong' is always relative. Unless
you have a specific reference of average strenth anything can be
considered strong or weak depending on point of view.
>
> >
> > You could make a case that 'impact' is significantly less frequent word
> > compared to effect/affect and thus makes the text harder to understand
> > for non-native speakers. However, that's not the point you brought up,
> > and even then it is very weak point to make, especially without any
> > actual source for the frequency data. You could also counter that all of
> > these are common loanwords in many languages and are thus easy to
> > understand to non-native speakers anyway.
> >
> > Thanks
> >
> > Michal
> > >
> > > Documentation/MyFirstContribution.txt | 2 +-
> > > Documentation/MyFirstObjectWalk.txt | 2 +-
> > > Documentation/config/pack.txt | 2 +-
> > > Documentation/git-fast-import.txt | 14 +++++++-------
> > > Documentation/git-fetch.txt | 2 +-
> > > .../technical/hash-function-transition.txt | 2 +-
> > > Documentation/user-manual.txt | 4 ++--
> > > advice.c | 2 +-
> > > builtin/fast-import.c | 2 +-
> > > builtin/pack-objects.c | 2 +-
> > > contrib/coccinelle/README | 2 +-
> > > dir.c | 2 +-
> > > t/perf/p5550-fetch-tags.sh | 2 +-
> > > t/t0008-ignores.sh | 2 +-
> > > t/t0303-credential-external.sh | 2 +-
> > > t/t2020-checkout-detach.sh | 4 ++--
> > > t/t4013-diff-various.sh | 2 +-
> > > t/t5000-tar-tree.sh | 2 +-
> > > t/test-lib-functions.sh | 2 +-
> > > 19 files changed, 27 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/Documentation/MyFirstContribution.txt
> > > b/Documentation/MyFirstContribution.txt
> > > index af0a9da62e..8372a7e59e 100644
> > > --- a/Documentation/MyFirstContribution.txt
> > > +++ b/Documentation/MyFirstContribution.txt
> > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> > > how to show it in the general
> > > command list shown by `git help git` or `git help -a`, which is generated from
> > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> > > line above it in alphabetical order. Now, we can add some attributes about the
> > > -command which impacts where it shows up in the aforementioned help
> > > commands. The
> > > +command which affects where it shows up in the aforementioned help
> > > commands. The
> > > top of `command-list.txt` shares some information about what each attribute
> > > means; in those help pages, the commands are sorted according to these
> > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> > > diff --git a/Documentation/MyFirstObjectWalk.txt
> > > b/Documentation/MyFirstObjectWalk.txt
> > > index 2d10eea7a9..fd5bb8fb7d 100644
> > > --- a/Documentation/MyFirstObjectWalk.txt
> > > +++ b/Documentation/MyFirstObjectWalk.txt
> > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> > > By running your walk with and without the filter, you should find
> > > that the total
> > > object count in each case is identical. You can also time each invocation of
> > > the `walken` subcommand, with and without `omitted` being passed in, to confirm
> > > -to yourself the runtime impact of tracking all omitted objects.
> > > +to yourself the runtime effect of tracking all omitted objects.
> > >
> > > === Changing the Order
> > >
> > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> > > index 3da4ea98e2..00fcc9d7c7 100644
> > > --- a/Documentation/config/pack.txt
> > > +++ b/Documentation/config/pack.txt
> > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> > > This cache is used to speed up the writing object phase by not
> > > having to recompute the final delta result once the best match
> > > for all objects is found. Repacking large repositories on machines
> > > - which are tight with memory might be badly impacted by this though,
> > > + which are tight with memory might be badly affected by this though,
> > > especially if this cache pushes the system into swapping.
> > > A value of 0 means no limit. The smallest size of 1 byte may be
> > > used to virtually disable this cache. Defaults to 256 MiB.
> > > diff --git a/Documentation/git-fast-import.txt
> > > b/Documentation/git-fast-import.txt
> > > index 39cfa05b28..c6d8e4e1d7 100644
> > > --- a/Documentation/git-fast-import.txt
> > > +++ b/Documentation/git-fast-import.txt
> > > @@ -58,7 +58,7 @@ OPTIONS
> > > allowing fast-import to access the filesystem outside of the
> > > repository). These options are disabled by default, but can be
> > > allowed by providing this option on the command line. This
> > > - currently impacts only the `export-marks`, `import-marks`, and
> > > + currently affects only the `export-marks`, `import-marks`, and
> > > `import-marks-if-exists` feature commands.
> > > +
> > > Only enable this option if you trust the program generating the
> > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
> > >
> > > A `filecopy` command takes effect immediately. Once the source
> > > location has been copied to the destination any future commands
> > > -applied to the source location will not impact the destination of
> > > +applied to the source location will not affect the destination of
> > > the copy.
> > >
> > > `filerename`
> > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> > > A `filerename` command takes effect immediately. Once the source
> > > location has been renamed to the destination any future commands
> > > applied to the source location will create new files there and not
> > > -impact the destination of the rename.
> > > +affect the destination of the rename.
> > >
> > > Note that a `filerename` is the same as a `filecopy` followed by a
> > > `filedelete` of the source location. There is a slight performance
> > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> > > to be required).
> > > ~~~~~~~~~~
> > > Causes fast-import to print the entire `progress` line unmodified to
> > > its standard output channel (file descriptor 1) when the command is
> > > -processed from the input stream. The command otherwise has no impact
> > > +processed from the input stream. The command otherwise has no effect
> > > on the current import, or on any of fast-import's internal state.
> > >
> > > ....
> > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> > > ~~~~~~~~~~
> > > Causes fast-import to print the SHA-1 corresponding to a mark to
> > > stdout or to the file descriptor previously arranged with the
> > > -`--cat-blob-fd` argument. The command otherwise has no impact on the
> > > +`--cat-blob-fd` argument. The command otherwise has no effect on the
> > > current import; its purpose is to retrieve SHA-1s that later commits
> > > might want to refer to in their commit messages.
> > >
> > > @@ -1050,7 +1050,7 @@ this output safely.
> > > ~~~~~~~~~~
> > > Causes fast-import to print a blob to a file descriptor previously
> > > arranged with the `--cat-blob-fd` argument. The command otherwise
> > > -has no impact on the current import; its main purpose is to
> > > +has no effect on the current import; its main purpose is to
> > > retrieve blobs that may be in fast-import's memory but not
> > > accessible from the target repository.
> > >
> > > @@ -1366,7 +1366,7 @@ code considerably.
> > >
> > > The branch LRU builtin to fast-import tends to behave very well, and the
> > > cost of activating an inactive branch is so low that bouncing around
> > > -between branches has virtually no impact on import performance.
> > > +between branches has virtually no effect on import performance.
> > >
> > > Handling Renames
> > > ~~~~~~~~~~~~~~~~
> > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> > > index 9067c2079e..01cf3b3d16 100644
> > > --- a/Documentation/git-fetch.txt
> > > +++ b/Documentation/git-fetch.txt
> > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> > > If left to accumulate, these stale references might make performance
> > > worse on big and busy repos that have a lot of branch churn, and
> > > e.g. make the output of commands like `git branch -a --contains
> > > -<commit>` needlessly verbose, as well as impacting anything else
> > > +<commit>` needlessly verbose, as well as affecting anything else
> > > that'll work with the complete set of known references.
> > >
> > > These remote-tracking references can be deleted as a one-off with
> > > diff --git a/Documentation/technical/hash-function-transition.txt
> > > b/Documentation/technical/hash-function-transition.txt
> > > index 7c1630bf83..f4296faffc 100644
> > > --- a/Documentation/technical/hash-function-transition.txt
> > > +++ b/Documentation/technical/hash-function-transition.txt
> > > @@ -42,7 +42,7 @@ mitigations.
> > >
> > > If SHA-1 and its variants were to be truly broken, Git's hash function
> > > could not be considered cryptographically secure any more. This would
> > > -impact the communication of hash values because we could not trust
> > > +affect the communication of hash values because we could not trust
> > > that a given hash value represented the known good version of content
> > > that the speaker intended.
> > >
> > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > > index fd480b8645..33c60c49d7 100644
> > > --- a/Documentation/user-manual.txt
> > > +++ b/Documentation/user-manual.txt
> > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
> > >
> > > You are in 'detached HEAD' state. You can look around, make experimental
> > > changes and commit them, and you can discard any commits you make in this
> > > -state without impacting any branches by performing another switch.
> > > +state without affecting any branches by performing another switch.
> > >
> > > If you want to create a new branch to retain commits you create, you may
> > > do so (now or later) by using -c with the switch command again. Example:
> > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> > > overwritten by the result of
> > > the merge when this combining is done cleanly, or overwritten by a
> > > half-merged results when this combining results in conflicts.
> > > Therefore, if you have uncommitted changes touching the same files as
> > > -the ones impacted by the merge, Git will refuse to proceed. Most of
> > > +the ones affected by the merge, Git will refuse to proceed. Most of
> > > the time, you will want to commit your changes before you can merge,
> > > and if you don't, then linkgit:git-stash[1] can take these changes
> > > away while you're doing the merge, and reapply them afterwards.
> > > diff --git a/advice.c b/advice.c
> > > index 164742305f..9cbbb824a9 100644
> > > --- a/advice.c
> > > +++ b/advice.c
> > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> > > "\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/builtin/fast-import.c b/builtin/fast-import.c
> > > index 3afa81cf9a..24f362d2f4 100644
> > > --- a/builtin/fast-import.c
> > > +++ b/builtin/fast-import.c
> > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> > > const char *prefix)
> > > * We don't parse most options until after we've seen the set of
> > > * "feature" lines at the start of the stream (which allows the command
> > > * line to override stream data). But we must do an early parse of any
> > > - * command-line options that impact how we interpret the feature lines.
> > > + * command-line options that affect how we interpret the feature lines.
> > > */
> > > for (i = 1; i < argc; i++) {
> > > const char *arg = argv[i];
> > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> > > index 525c2d8552..749bbca241 100644
> > > --- a/builtin/pack-objects.c
> > > +++ b/builtin/pack-objects.c
> > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> > > /*
> > > * Mark ourselves as active and see if the next step causes
> > > * us to cycle to another active object. It's important to do
> > > - * this _before_ we loop, because it impacts where we make the
> > > + * this _before_ we loop, because it affects where we make the
> > > * cut, and thus how our total_depth counter works.
> > > * E.g., We may see a partial loop like:
> > > *
> > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> > > index f0e80bd7f0..92979ec770 100644
> > > --- a/contrib/coccinelle/README
> > > +++ b/contrib/coccinelle/README
> > > @@ -40,4 +40,4 @@ There are two types of semantic patches:
> > > are ignored for checks, and can be applied using 'make coccicheck-pending'.
> > >
> > > This allows to expose plans of pending large scale refactorings without
> > > - impacting the bad pattern checks.
> > > + affecting the bad pattern checks.
> > > diff --git a/dir.c b/dir.c
> > > index 3474e67e8f..235e26a90e 100644
> > > --- a/dir.c
> > > +++ b/dir.c
> > > @@ -2144,7 +2144,7 @@ static enum path_treatment
> > > treat_path_fast(struct dir_struct *dir,
> > > /*
> > > * We get path_recurse in the first run when
> > > * directory_exists_in_index() returns index_nonexistent. We
> > > - * are sure that new changes in the index does not impact the
> > > + * are sure that new changes in the index does not affect the
> > > * outcome. Return now.
> > > */
> > > return path_recurse;
> > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> > > index d0e0e019ea..1fcb98443c 100755
> > > --- a/t/perf/p5550-fetch-tags.sh
> > > +++ b/t/perf/p5550-fetch-tags.sh
> > > @@ -8,7 +8,7 @@ follows.
> > >
> > > The parent repository has a large number of tags which are disconnected from
> > > the rest of history. That makes them candidates for tag-following, but we never
> > > -actually grab them (and thus they will impact each subsequent fetch).
> > > +actually grab them (and thus they will affect each subsequent fetch).
> > >
> > > The child repository is a clone of parent, without the tags, and is at least
> > > one commit behind the parent (meaning that we will fetch one object and then
> > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> > > index a594b4aa7d..95daba4000 100755
> > > --- a/t/t0008-ignores.sh
> > > +++ b/t/t0008-ignores.sh
> > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> > > # test standard ignores
> > >
> > > # First make sure that the presence of a file in the working tree
> > > -# does not impact results, but that the presence of a file in the
> > > +# does not affect results, but that the presence of a file in the
> > > # index does unless the --no-index option is used.
> > >
> > > for subdir in '' 'a/'
> > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> > > index f028fd1418..a9348f655a 100755
> > > --- a/t/t0303-credential-external.sh
> > > +++ b/t/t0303-credential-external.sh
> > > @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> > > eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
> > >
> > > # clean before the test in case there is cruft left
> > > -# over from a previous run that would impact results
> > > +# over from a previous run that would affect results
> > > helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
> > >
> > > helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> > > index bc46713a43..568c258c5a 100755
> > > --- a/t/t2020-checkout-detach.sh
> > > +++ b/t/t2020-checkout-detach.sh
> > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> > > no SHA-1 ellipsis when not as
> > >
> > > You are in 'detached HEAD' state. You can look around, make experimental
> > > changes and commit them, and you can discard any commits you make in this
> > > - state without impacting any branches by switching back to a branch.
> > > + state without affecting any branches by switching back to a branch.
> > >
> > > If you want to create a new branch to retain commits you create, you may
> > > do so (now or later) by using -c with the switch command. Example:
> > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> > > print SHA-1 ellipsis when asked
> > >
> > > You are in 'detached HEAD' state. You can look around, make experimental
> > > changes and commit them, and you can discard any commits you make in this
> > > - state without impacting any branches by switching back to a branch.
> > > + state without affecting any branches by switching back to a branch.
> > >
> > > If you want to create a new branch to retain commits you create, you may
> > > do so (now or later) by using -c with the switch command. Example:
> > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> > > index 6cca8b84a6..97365a7786 100755
> > > --- a/t/t4013-diff-various.sh
> > > +++ b/t/t4013-diff-various.sh
> > > @@ -109,7 +109,7 @@ test_expect_success setup '
> > > git checkout -f master &&
> > >
> > > # Same merge as master, but with parents reversed. Hide it in a
> > > - # pseudo-ref to avoid impacting tests with --all.
> > > + # pseudo-ref to avoid affecting tests with --all.
> > > commit=$(echo reverse |
> > > git commit-tree -p master^2 -p master^1 master^{tree}) &&
> > > git update-ref REVERSE $commit &&
> > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> > > index 7204799a0b..33a6efce2f 100755
> > > --- a/t/t5000-tar-tree.sh
> > > +++ b/t/t5000-tar-tree.sh
> > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> > > # Pull the size and date of each entry in a tarfile using the system tar.
> > > #
> > > # We'll pull out only the year from the date; that avoids any question of
> > > -# timezones impacting the result (as long as we keep our test times away from a
> > > +# timezones affecting the result (as long as we keep our test times away from a
> > > # year boundary; our reference times are all in August).
> > > #
> > > # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> > > index 6348e8d733..ff65f86f50 100644
> > > --- a/t/test-lib-functions.sh
> > > +++ b/t/test-lib-functions.sh
> > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> > > }
> > >
> > > # Like "env FOO=BAR some-program", but run inside a subshell, which means
> > > -# it also works for shell functions (though those functions cannot impact
> > > +# it also works for shell functions (though those functions cannot affect
> > > # the environment outside of the test_env invocation).
> > > test_env () {
> > > (
> > > --
> > > 2.17.1
> > >
> > > On Tue, 6 Apr 2021 at 19:06, Varun Varada <varuncvarada@gmail.com> wrote:
> > > >
> > > > On Tue, 6 Apr 2021 at 18:01, Jeff King <peff@peff.net> wrote:
> > > > >
> > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
> > > > >
> > > > > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > > > > problem the word "impact" in itself is not "jargon".
> > > > > >
> > > > > > The word means "to have a strong or marked effect on" (v.) and "a
> > > > > > strong or market influence" (n.) when used figuratively; it is not
> > > > > > synonymous with "affect" and "effect", respectively, as shown even by
> > > > > > all of the entries you've cited. Using it as such is the incorrect
> > > > > > part, so those are the instances I've changed in the diff.
> > > > >
> > > > > Er, is that true? From Michal's definitions:
> > > > >
> > > > > > > From The Collaborative International Dictionary of English v.0.48 :
> > > > > > [...]
> > > > > > > 2. To affect or influence, especially in a significant or
> > > > >
> > > > > It literally uses "affect" to define it. The "especially significant"
> > > > > does not apply to many, but I don't think that makes it necessarily
> > > > > wrong to use impact to mean "affect".
> > > >
> > > > I was drawing attention to the "especially significant" bit and the
> > > > like being there in all the entries. I'm not sure about these
> > > > dictionaries, but the definition is hyperbolic / violent / shocking in
> > > > every reputable dictionary out there: the Oxford English Dictionary,
> > > > Merriam-Webster, and Collins.
> > > >
> > > > >
> > > > > Likewise:
> > > > >
> > > > > > > From WordNet (r) 3.0 (2006) :
> > > > > > [...]
> > > > > > > v 1: press or wedge together; pack together
> > > > > > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > > > > > affect, impact, bear upon, bear on, touch on,
> > > > > > > touch]
> > > > >
> > > > > That is likewise listing "impact" and "affect" as synonyms.
> > > > >
> > > > > I do agree the word is over-used in some forms of writing, but I don't
> > > > > find anything at all confusing or wrong about the uses that you changed
> > > > > in your patch. I am a native speaker of English. I'm open to the
> > > > > argument that non-native speakers may be more confused by the word. But
> > > > > this seems like mostly a style preference thing, and I'd generally
> > > > > prefer to leave the contributions and style of the original writers
> > > > > intact unless there is a good reason not to.
> > > >
> > > > I am a native English speaker as well, and there were multiple places
> > > > where I had to think twice about what the sentences mean. I agree with
> > > > your sentiment about leaving stylistic preferences intact, but this is
> > > > actually a semantic one. And given that there is a perfectly good
> > > > alternative that doesn't have this confusion / jargon status, I wanted
> > > > to make the change to improve it, especially where it says that in the
> > > > output of the git command (`git checkout` when in detached HEAD mode).
> > > >
> > > > >
> > > > > Such changes are doubly unwanted in cases like this:
> > > > >
> > > > > > --- a/compat/nedmalloc/malloc.c.h
> > > > > > +++ b/compat/nedmalloc/malloc.c.h
> > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > > > > > #endif /* (FOOTERS && !INSECURE) */
> > > > > >
> > > > > >
> > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > > > > > #if !INSECURE
> > > > > > #if defined(__GNUC__) && __GNUC__ >= 3
> > > > > > #define RTCHECK(e) __builtin_expect(e, 1)
> > > > >
> > > > > where the text is imported from another project, and we'd prefer to stay
> > > > > as close to their version as possible (e.g., to avoid unnecessary
> > > > > conflicts when pulling in new versions).
> > > >
> > > > That's fair; I wasn't aware that this was being pulled directly from
> > > > another project. I can change this back.
> > > >
> > > > >
> > > > > Also, this one should be "effect" anyway, as it is a noun.
> > > >
> > > > This seems to have slipped through, as I used a text search tool.
> > > >
> > > > >
> > > > > -Peff
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-28 18:49 ` Michal Suchánek
@ 2021-04-30 1:51 ` Varun Varada
2021-04-30 7:59 ` Michal Suchánek
2021-05-12 2:38 ` Felipe Contreras
1 sibling, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-04-30 1:51 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Jeff King, git
On Wed, 28 Apr 2021 at 13:49, Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:
> > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek <msuchanek@suse.de> wrote:
> > >
> > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:
> > > > Here's the updated diff:
> > >
> > > As already said multiple general purpose dictionaries recognize '(have)
> > > strong effect' as the meaning of 'impact', in some cases even the most
> > > common meaning.
> >
> > There's no contention here. That's the meaning I've been referring to as well.
> >
> > >
> > > In case you have some issue with the word 'jargon' Merriam-Webster gives
> > > this definition:
> > >
> > > 1: the technical terminology or characteristic idiom of a special activity or group
> > > 2: obscure and often pretentious language marked by circumlocutions and long words
> > > 3a: confused unintelligible language
> > > b: a strange, outlandish, or barbarous language or dialect
> > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech
> > >
> > > which the word 'impact' does not fulfill.
> > >
> > > Further, you would rarely discuss and document an effect that is
> > > negligible so in vast majority of cases '(have) strong effect' (ie
> > > 'impact') is synonymous to 'affect' and 'affect', respectively.
> >
> > This is not true, especially in technical contexts. "Affect" doesn't
> > mean "has a slight effect on", but simply "has an effect on". This
> > suffices in most cases. In cases where one would like to highlight the
> > overwhelming/awesome/debilitating/marked/strong effect that something
> > has, "impact" can be used. To say that every effect is overwhelming or
> > strong is jargon.
> >
> > >
> > > If you can pick out a few places where the use is specifically confusing
> > > then please pick out those. Wholesale replacement of one word with
> > > another synonym is not desired. It creates useless churn.
> >
> > I've actually not done a wholesale replacement blindly; the ones I
> > replaced are the places where I couldn't find any case where it is
> > referring to a "strong/marked effect". This is especially true in the
> > negative constructions. If you could help me find places where you
> > think the intended meaning is indeed "a strong/marked effect", I can
> > remove those from the changes.
>
> As already pointed out before the mere fact that the author of the text
> bothered to document the effect ipmlies that the effect is strong/marked
> unless stated otherwise. At any rate 'strong' is always relative. Unless
> you have a specific reference of average strenth anything can be
> considered strong or weak depending on point of view.
This doesn't seem like a plausible or strong argument given the
context of the places where I'm editing the text. Most of them are
negative constructions, where if one were to assume "strongly affect"
was intended, then that raises the question of what actual effect it
will have. The only convincing example of this I can see is the one
where it reads "which are tight with memory might be badly impacted by
this though". All of the other ones seem like they're binary in
whether they will have an effect at all or no, not graduated in terms
of the degree of the effect it will have.
>
> >
> > >
> > > You could make a case that 'impact' is significantly less frequent word
> > > compared to effect/affect and thus makes the text harder to understand
> > > for non-native speakers. However, that's not the point you brought up,
> > > and even then it is very weak point to make, especially without any
> > > actual source for the frequency data. You could also counter that all of
> > > these are common loanwords in many languages and are thus easy to
> > > understand to non-native speakers anyway.
> > >
> > > Thanks
> > >
> > > Michal
> > > >
> > > > Documentation/MyFirstContribution.txt | 2 +-
> > > > Documentation/MyFirstObjectWalk.txt | 2 +-
> > > > Documentation/config/pack.txt | 2 +-
> > > > Documentation/git-fast-import.txt | 14 +++++++-------
> > > > Documentation/git-fetch.txt | 2 +-
> > > > .../technical/hash-function-transition.txt | 2 +-
> > > > Documentation/user-manual.txt | 4 ++--
> > > > advice.c | 2 +-
> > > > builtin/fast-import.c | 2 +-
> > > > builtin/pack-objects.c | 2 +-
> > > > contrib/coccinelle/README | 2 +-
> > > > dir.c | 2 +-
> > > > t/perf/p5550-fetch-tags.sh | 2 +-
> > > > t/t0008-ignores.sh | 2 +-
> > > > t/t0303-credential-external.sh | 2 +-
> > > > t/t2020-checkout-detach.sh | 4 ++--
> > > > t/t4013-diff-various.sh | 2 +-
> > > > t/t5000-tar-tree.sh | 2 +-
> > > > t/test-lib-functions.sh | 2 +-
> > > > 19 files changed, 27 insertions(+), 27 deletions(-)
> > > >
> > > > diff --git a/Documentation/MyFirstContribution.txt
> > > > b/Documentation/MyFirstContribution.txt
> > > > index af0a9da62e..8372a7e59e 100644
> > > > --- a/Documentation/MyFirstContribution.txt
> > > > +++ b/Documentation/MyFirstContribution.txt
> > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> > > > how to show it in the general
> > > > command list shown by `git help git` or `git help -a`, which is generated from
> > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> > > > line above it in alphabetical order. Now, we can add some attributes about the
> > > > -command which impacts where it shows up in the aforementioned help
> > > > commands. The
> > > > +command which affects where it shows up in the aforementioned help
> > > > commands. The
> > > > top of `command-list.txt` shares some information about what each attribute
> > > > means; in those help pages, the commands are sorted according to these
> > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> > > > diff --git a/Documentation/MyFirstObjectWalk.txt
> > > > b/Documentation/MyFirstObjectWalk.txt
> > > > index 2d10eea7a9..fd5bb8fb7d 100644
> > > > --- a/Documentation/MyFirstObjectWalk.txt
> > > > +++ b/Documentation/MyFirstObjectWalk.txt
> > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> > > > By running your walk with and without the filter, you should find
> > > > that the total
> > > > object count in each case is identical. You can also time each invocation of
> > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm
> > > > -to yourself the runtime impact of tracking all omitted objects.
> > > > +to yourself the runtime effect of tracking all omitted objects.
> > > >
> > > > === Changing the Order
> > > >
> > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> > > > index 3da4ea98e2..00fcc9d7c7 100644
> > > > --- a/Documentation/config/pack.txt
> > > > +++ b/Documentation/config/pack.txt
> > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> > > > This cache is used to speed up the writing object phase by not
> > > > having to recompute the final delta result once the best match
> > > > for all objects is found. Repacking large repositories on machines
> > > > - which are tight with memory might be badly impacted by this though,
> > > > + which are tight with memory might be badly affected by this though,
> > > > especially if this cache pushes the system into swapping.
> > > > A value of 0 means no limit. The smallest size of 1 byte may be
> > > > used to virtually disable this cache. Defaults to 256 MiB.
> > > > diff --git a/Documentation/git-fast-import.txt
> > > > b/Documentation/git-fast-import.txt
> > > > index 39cfa05b28..c6d8e4e1d7 100644
> > > > --- a/Documentation/git-fast-import.txt
> > > > +++ b/Documentation/git-fast-import.txt
> > > > @@ -58,7 +58,7 @@ OPTIONS
> > > > allowing fast-import to access the filesystem outside of the
> > > > repository). These options are disabled by default, but can be
> > > > allowed by providing this option on the command line. This
> > > > - currently impacts only the `export-marks`, `import-marks`, and
> > > > + currently affects only the `export-marks`, `import-marks`, and
> > > > `import-marks-if-exists` feature commands.
> > > > +
> > > > Only enable this option if you trust the program generating the
> > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
> > > >
> > > > A `filecopy` command takes effect immediately. Once the source
> > > > location has been copied to the destination any future commands
> > > > -applied to the source location will not impact the destination of
> > > > +applied to the source location will not affect the destination of
> > > > the copy.
> > > >
> > > > `filerename`
> > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> > > > A `filerename` command takes effect immediately. Once the source
> > > > location has been renamed to the destination any future commands
> > > > applied to the source location will create new files there and not
> > > > -impact the destination of the rename.
> > > > +affect the destination of the rename.
> > > >
> > > > Note that a `filerename` is the same as a `filecopy` followed by a
> > > > `filedelete` of the source location. There is a slight performance
> > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> > > > to be required).
> > > > ~~~~~~~~~~
> > > > Causes fast-import to print the entire `progress` line unmodified to
> > > > its standard output channel (file descriptor 1) when the command is
> > > > -processed from the input stream. The command otherwise has no impact
> > > > +processed from the input stream. The command otherwise has no effect
> > > > on the current import, or on any of fast-import's internal state.
> > > >
> > > > ....
> > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> > > > ~~~~~~~~~~
> > > > Causes fast-import to print the SHA-1 corresponding to a mark to
> > > > stdout or to the file descriptor previously arranged with the
> > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the
> > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the
> > > > current import; its purpose is to retrieve SHA-1s that later commits
> > > > might want to refer to in their commit messages.
> > > >
> > > > @@ -1050,7 +1050,7 @@ this output safely.
> > > > ~~~~~~~~~~
> > > > Causes fast-import to print a blob to a file descriptor previously
> > > > arranged with the `--cat-blob-fd` argument. The command otherwise
> > > > -has no impact on the current import; its main purpose is to
> > > > +has no effect on the current import; its main purpose is to
> > > > retrieve blobs that may be in fast-import's memory but not
> > > > accessible from the target repository.
> > > >
> > > > @@ -1366,7 +1366,7 @@ code considerably.
> > > >
> > > > The branch LRU builtin to fast-import tends to behave very well, and the
> > > > cost of activating an inactive branch is so low that bouncing around
> > > > -between branches has virtually no impact on import performance.
> > > > +between branches has virtually no effect on import performance.
> > > >
> > > > Handling Renames
> > > > ~~~~~~~~~~~~~~~~
> > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> > > > index 9067c2079e..01cf3b3d16 100644
> > > > --- a/Documentation/git-fetch.txt
> > > > +++ b/Documentation/git-fetch.txt
> > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> > > > If left to accumulate, these stale references might make performance
> > > > worse on big and busy repos that have a lot of branch churn, and
> > > > e.g. make the output of commands like `git branch -a --contains
> > > > -<commit>` needlessly verbose, as well as impacting anything else
> > > > +<commit>` needlessly verbose, as well as affecting anything else
> > > > that'll work with the complete set of known references.
> > > >
> > > > These remote-tracking references can be deleted as a one-off with
> > > > diff --git a/Documentation/technical/hash-function-transition.txt
> > > > b/Documentation/technical/hash-function-transition.txt
> > > > index 7c1630bf83..f4296faffc 100644
> > > > --- a/Documentation/technical/hash-function-transition.txt
> > > > +++ b/Documentation/technical/hash-function-transition.txt
> > > > @@ -42,7 +42,7 @@ mitigations.
> > > >
> > > > If SHA-1 and its variants were to be truly broken, Git's hash function
> > > > could not be considered cryptographically secure any more. This would
> > > > -impact the communication of hash values because we could not trust
> > > > +affect the communication of hash values because we could not trust
> > > > that a given hash value represented the known good version of content
> > > > that the speaker intended.
> > > >
> > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > > > index fd480b8645..33c60c49d7 100644
> > > > --- a/Documentation/user-manual.txt
> > > > +++ b/Documentation/user-manual.txt
> > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
> > > >
> > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > changes and commit them, and you can discard any commits you make in this
> > > > -state without impacting any branches by performing another switch.
> > > > +state without affecting any branches by performing another switch.
> > > >
> > > > If you want to create a new branch to retain commits you create, you may
> > > > do so (now or later) by using -c with the switch command again. Example:
> > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> > > > overwritten by the result of
> > > > the merge when this combining is done cleanly, or overwritten by a
> > > > half-merged results when this combining results in conflicts.
> > > > Therefore, if you have uncommitted changes touching the same files as
> > > > -the ones impacted by the merge, Git will refuse to proceed. Most of
> > > > +the ones affected by the merge, Git will refuse to proceed. Most of
> > > > the time, you will want to commit your changes before you can merge,
> > > > and if you don't, then linkgit:git-stash[1] can take these changes
> > > > away while you're doing the merge, and reapply them afterwards.
> > > > diff --git a/advice.c b/advice.c
> > > > index 164742305f..9cbbb824a9 100644
> > > > --- a/advice.c
> > > > +++ b/advice.c
> > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> > > > "\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/builtin/fast-import.c b/builtin/fast-import.c
> > > > index 3afa81cf9a..24f362d2f4 100644
> > > > --- a/builtin/fast-import.c
> > > > +++ b/builtin/fast-import.c
> > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> > > > const char *prefix)
> > > > * We don't parse most options until after we've seen the set of
> > > > * "feature" lines at the start of the stream (which allows the command
> > > > * line to override stream data). But we must do an early parse of any
> > > > - * command-line options that impact how we interpret the feature lines.
> > > > + * command-line options that affect how we interpret the feature lines.
> > > > */
> > > > for (i = 1; i < argc; i++) {
> > > > const char *arg = argv[i];
> > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> > > > index 525c2d8552..749bbca241 100644
> > > > --- a/builtin/pack-objects.c
> > > > +++ b/builtin/pack-objects.c
> > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> > > > /*
> > > > * Mark ourselves as active and see if the next step causes
> > > > * us to cycle to another active object. It's important to do
> > > > - * this _before_ we loop, because it impacts where we make the
> > > > + * this _before_ we loop, because it affects where we make the
> > > > * cut, and thus how our total_depth counter works.
> > > > * E.g., We may see a partial loop like:
> > > > *
> > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> > > > index f0e80bd7f0..92979ec770 100644
> > > > --- a/contrib/coccinelle/README
> > > > +++ b/contrib/coccinelle/README
> > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:
> > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.
> > > >
> > > > This allows to expose plans of pending large scale refactorings without
> > > > - impacting the bad pattern checks.
> > > > + affecting the bad pattern checks.
> > > > diff --git a/dir.c b/dir.c
> > > > index 3474e67e8f..235e26a90e 100644
> > > > --- a/dir.c
> > > > +++ b/dir.c
> > > > @@ -2144,7 +2144,7 @@ static enum path_treatment
> > > > treat_path_fast(struct dir_struct *dir,
> > > > /*
> > > > * We get path_recurse in the first run when
> > > > * directory_exists_in_index() returns index_nonexistent. We
> > > > - * are sure that new changes in the index does not impact the
> > > > + * are sure that new changes in the index does not affect the
> > > > * outcome. Return now.
> > > > */
> > > > return path_recurse;
> > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> > > > index d0e0e019ea..1fcb98443c 100755
> > > > --- a/t/perf/p5550-fetch-tags.sh
> > > > +++ b/t/perf/p5550-fetch-tags.sh
> > > > @@ -8,7 +8,7 @@ follows.
> > > >
> > > > The parent repository has a large number of tags which are disconnected from
> > > > the rest of history. That makes them candidates for tag-following, but we never
> > > > -actually grab them (and thus they will impact each subsequent fetch).
> > > > +actually grab them (and thus they will affect each subsequent fetch).
> > > >
> > > > The child repository is a clone of parent, without the tags, and is at least
> > > > one commit behind the parent (meaning that we will fetch one object and then
> > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> > > > index a594b4aa7d..95daba4000 100755
> > > > --- a/t/t0008-ignores.sh
> > > > +++ b/t/t0008-ignores.sh
> > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> > > > # test standard ignores
> > > >
> > > > # First make sure that the presence of a file in the working tree
> > > > -# does not impact results, but that the presence of a file in the
> > > > +# does not affect results, but that the presence of a file in the
> > > > # index does unless the --no-index option is used.
> > > >
> > > > for subdir in '' 'a/'
> > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> > > > index f028fd1418..a9348f655a 100755
> > > > --- a/t/t0303-credential-external.sh
> > > > +++ b/t/t0303-credential-external.sh
> > > > @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> > > > eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
> > > >
> > > > # clean before the test in case there is cruft left
> > > > -# over from a previous run that would impact results
> > > > +# over from a previous run that would affect results
> > > > helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
> > > >
> > > > helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> > > > index bc46713a43..568c258c5a 100755
> > > > --- a/t/t2020-checkout-detach.sh
> > > > +++ b/t/t2020-checkout-detach.sh
> > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> > > > no SHA-1 ellipsis when not as
> > > >
> > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > changes and commit them, and you can discard any commits you make in this
> > > > - state without impacting any branches by switching back to a branch.
> > > > + state without affecting any branches by switching back to a branch.
> > > >
> > > > If you want to create a new branch to retain commits you create, you may
> > > > do so (now or later) by using -c with the switch command. Example:
> > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> > > > print SHA-1 ellipsis when asked
> > > >
> > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > changes and commit them, and you can discard any commits you make in this
> > > > - state without impacting any branches by switching back to a branch.
> > > > + state without affecting any branches by switching back to a branch.
> > > >
> > > > If you want to create a new branch to retain commits you create, you may
> > > > do so (now or later) by using -c with the switch command. Example:
> > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> > > > index 6cca8b84a6..97365a7786 100755
> > > > --- a/t/t4013-diff-various.sh
> > > > +++ b/t/t4013-diff-various.sh
> > > > @@ -109,7 +109,7 @@ test_expect_success setup '
> > > > git checkout -f master &&
> > > >
> > > > # Same merge as master, but with parents reversed. Hide it in a
> > > > - # pseudo-ref to avoid impacting tests with --all.
> > > > + # pseudo-ref to avoid affecting tests with --all.
> > > > commit=$(echo reverse |
> > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&
> > > > git update-ref REVERSE $commit &&
> > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> > > > index 7204799a0b..33a6efce2f 100755
> > > > --- a/t/t5000-tar-tree.sh
> > > > +++ b/t/t5000-tar-tree.sh
> > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> > > > # Pull the size and date of each entry in a tarfile using the system tar.
> > > > #
> > > > # We'll pull out only the year from the date; that avoids any question of
> > > > -# timezones impacting the result (as long as we keep our test times away from a
> > > > +# timezones affecting the result (as long as we keep our test times away from a
> > > > # year boundary; our reference times are all in August).
> > > > #
> > > > # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> > > > index 6348e8d733..ff65f86f50 100644
> > > > --- a/t/test-lib-functions.sh
> > > > +++ b/t/test-lib-functions.sh
> > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> > > > }
> > > >
> > > > # Like "env FOO=BAR some-program", but run inside a subshell, which means
> > > > -# it also works for shell functions (though those functions cannot impact
> > > > +# it also works for shell functions (though those functions cannot affect
> > > > # the environment outside of the test_env invocation).
> > > > test_env () {
> > > > (
> > > > --
> > > > 2.17.1
> > > >
> > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada <varuncvarada@gmail.com> wrote:
> > > > >
> > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King <peff@peff.net> wrote:
> > > > > >
> > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
> > > > > >
> > > > > > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > > > > > problem the word "impact" in itself is not "jargon".
> > > > > > >
> > > > > > > The word means "to have a strong or marked effect on" (v.) and "a
> > > > > > > strong or market influence" (n.) when used figuratively; it is not
> > > > > > > synonymous with "affect" and "effect", respectively, as shown even by
> > > > > > > all of the entries you've cited. Using it as such is the incorrect
> > > > > > > part, so those are the instances I've changed in the diff.
> > > > > >
> > > > > > Er, is that true? From Michal's definitions:
> > > > > >
> > > > > > > > From The Collaborative International Dictionary of English v.0.48 :
> > > > > > > [...]
> > > > > > > > 2. To affect or influence, especially in a significant or
> > > > > >
> > > > > > It literally uses "affect" to define it. The "especially significant"
> > > > > > does not apply to many, but I don't think that makes it necessarily
> > > > > > wrong to use impact to mean "affect".
> > > > >
> > > > > I was drawing attention to the "especially significant" bit and the
> > > > > like being there in all the entries. I'm not sure about these
> > > > > dictionaries, but the definition is hyperbolic / violent / shocking in
> > > > > every reputable dictionary out there: the Oxford English Dictionary,
> > > > > Merriam-Webster, and Collins.
> > > > >
> > > > > >
> > > > > > Likewise:
> > > > > >
> > > > > > > > From WordNet (r) 3.0 (2006) :
> > > > > > > [...]
> > > > > > > > v 1: press or wedge together; pack together
> > > > > > > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > > > > > > affect, impact, bear upon, bear on, touch on,
> > > > > > > > touch]
> > > > > >
> > > > > > That is likewise listing "impact" and "affect" as synonyms.
> > > > > >
> > > > > > I do agree the word is over-used in some forms of writing, but I don't
> > > > > > find anything at all confusing or wrong about the uses that you changed
> > > > > > in your patch. I am a native speaker of English. I'm open to the
> > > > > > argument that non-native speakers may be more confused by the word. But
> > > > > > this seems like mostly a style preference thing, and I'd generally
> > > > > > prefer to leave the contributions and style of the original writers
> > > > > > intact unless there is a good reason not to.
> > > > >
> > > > > I am a native English speaker as well, and there were multiple places
> > > > > where I had to think twice about what the sentences mean. I agree with
> > > > > your sentiment about leaving stylistic preferences intact, but this is
> > > > > actually a semantic one. And given that there is a perfectly good
> > > > > alternative that doesn't have this confusion / jargon status, I wanted
> > > > > to make the change to improve it, especially where it says that in the
> > > > > output of the git command (`git checkout` when in detached HEAD mode).
> > > > >
> > > > > >
> > > > > > Such changes are doubly unwanted in cases like this:
> > > > > >
> > > > > > > --- a/compat/nedmalloc/malloc.c.h
> > > > > > > +++ b/compat/nedmalloc/malloc.c.h
> > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > > > > > > #endif /* (FOOTERS && !INSECURE) */
> > > > > > >
> > > > > > >
> > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > > > > > > #if !INSECURE
> > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3
> > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)
> > > > > >
> > > > > > where the text is imported from another project, and we'd prefer to stay
> > > > > > as close to their version as possible (e.g., to avoid unnecessary
> > > > > > conflicts when pulling in new versions).
> > > > >
> > > > > That's fair; I wasn't aware that this was being pulled directly from
> > > > > another project. I can change this back.
> > > > >
> > > > > >
> > > > > > Also, this one should be "effect" anyway, as it is a noun.
> > > > >
> > > > > This seems to have slipped through, as I used a text search tool.
> > > > >
> > > > > >
> > > > > > -Peff
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-30 1:51 ` Varun Varada
@ 2021-04-30 7:59 ` Michal Suchánek
2021-05-10 17:19 ` Varun Varada
0 siblings, 1 reply; 68+ messages in thread
From: Michal Suchánek @ 2021-04-30 7:59 UTC (permalink / raw)
To: Varun Varada; +Cc: Jeff King, git
On Thu, Apr 29, 2021 at 08:51:07PM -0500, Varun Varada wrote:
> On Wed, 28 Apr 2021 at 13:49, Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:
> > > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek <msuchanek@suse.de> wrote:
> > > >
> > > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:
> > > > > Here's the updated diff:
> > > >
> > > > As already said multiple general purpose dictionaries recognize '(have)
> > > > strong effect' as the meaning of 'impact', in some cases even the most
> > > > common meaning.
> > >
> > > There's no contention here. That's the meaning I've been referring to as well.
> > >
> > > >
> > > > In case you have some issue with the word 'jargon' Merriam-Webster gives
> > > > this definition:
> > > >
> > > > 1: the technical terminology or characteristic idiom of a special activity or group
> > > > 2: obscure and often pretentious language marked by circumlocutions and long words
> > > > 3a: confused unintelligible language
> > > > b: a strange, outlandish, or barbarous language or dialect
> > > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech
> > > >
> > > > which the word 'impact' does not fulfill.
> > > >
> > > > Further, you would rarely discuss and document an effect that is
> > > > negligible so in vast majority of cases '(have) strong effect' (ie
> > > > 'impact') is synonymous to 'affect' and 'affect', respectively.
> > >
> > > This is not true, especially in technical contexts. "Affect" doesn't
> > > mean "has a slight effect on", but simply "has an effect on". This
> > > suffices in most cases. In cases where one would like to highlight the
> > > overwhelming/awesome/debilitating/marked/strong effect that something
> > > has, "impact" can be used. To say that every effect is overwhelming or
> > > strong is jargon.
> > >
> > > >
> > > > If you can pick out a few places where the use is specifically confusing
> > > > then please pick out those. Wholesale replacement of one word with
> > > > another synonym is not desired. It creates useless churn.
> > >
> > > I've actually not done a wholesale replacement blindly; the ones I
> > > replaced are the places where I couldn't find any case where it is
> > > referring to a "strong/marked effect". This is especially true in the
> > > negative constructions. If you could help me find places where you
> > > think the intended meaning is indeed "a strong/marked effect", I can
> > > remove those from the changes.
> >
> > As already pointed out before the mere fact that the author of the text
> > bothered to document the effect ipmlies that the effect is strong/marked
> > unless stated otherwise. At any rate 'strong' is always relative. Unless
> > you have a specific reference of average strenth anything can be
> > considered strong or weak depending on point of view.
>
> This doesn't seem like a plausible or strong argument given the
> context of the places where I'm editing the text. Most of them are
> negative constructions, where if one were to assume "strongly affect"
That's not the case. There are some which include negation, and many
that don't. I did not review all of the patch so can't really tell but
it looks like the onse that include negation are a minority or about
half of what you replace at best.
> was intended, then that raises the question of what actual effect it
> will have. The only convincing example of this I can see is the one
> where it reads "which are tight with memory might be badly impacted by
> this though". All of the other ones seem like they're binary in
> whether they will have an effect at all or no, not graduated in terms
> of the degree of the effect it will have.
Which also means that the distinction between 'strong effect' and
'effect' is meaningless, and 'affect' vs 'impact' is synonymous.
Replacing one with the other is useless churn then.
Also the cases I saw do not really look confusing in any way so the
change does not improve the documentation in any way.
>
> >
> > >
> > > >
> > > > You could make a case that 'impact' is significantly less frequent word
> > > > compared to effect/affect and thus makes the text harder to understand
> > > > for non-native speakers. However, that's not the point you brought up,
> > > > and even then it is very weak point to make, especially without any
> > > > actual source for the frequency data. You could also counter that all of
> > > > these are common loanwords in many languages and are thus easy to
> > > > understand to non-native speakers anyway.
> > > >
> > > > Thanks
> > > >
> > > > Michal
> > > > >
> > > > > Documentation/MyFirstContribution.txt | 2 +-
> > > > > Documentation/MyFirstObjectWalk.txt | 2 +-
> > > > > Documentation/config/pack.txt | 2 +-
> > > > > Documentation/git-fast-import.txt | 14 +++++++-------
> > > > > Documentation/git-fetch.txt | 2 +-
> > > > > .../technical/hash-function-transition.txt | 2 +-
> > > > > Documentation/user-manual.txt | 4 ++--
> > > > > advice.c | 2 +-
> > > > > builtin/fast-import.c | 2 +-
> > > > > builtin/pack-objects.c | 2 +-
> > > > > contrib/coccinelle/README | 2 +-
> > > > > dir.c | 2 +-
> > > > > t/perf/p5550-fetch-tags.sh | 2 +-
> > > > > t/t0008-ignores.sh | 2 +-
> > > > > t/t0303-credential-external.sh | 2 +-
> > > > > t/t2020-checkout-detach.sh | 4 ++--
> > > > > t/t4013-diff-various.sh | 2 +-
> > > > > t/t5000-tar-tree.sh | 2 +-
> > > > > t/test-lib-functions.sh | 2 +-
> > > > > 19 files changed, 27 insertions(+), 27 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/MyFirstContribution.txt
> > > > > b/Documentation/MyFirstContribution.txt
> > > > > index af0a9da62e..8372a7e59e 100644
> > > > > --- a/Documentation/MyFirstContribution.txt
> > > > > +++ b/Documentation/MyFirstContribution.txt
> > > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> > > > > how to show it in the general
> > > > > command list shown by `git help git` or `git help -a`, which is generated from
> > > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> > > > > line above it in alphabetical order. Now, we can add some attributes about the
> > > > > -command which impacts where it shows up in the aforementioned help
> > > > > commands. The
> > > > > +command which affects where it shows up in the aforementioned help
> > > > > commands. The
> > > > > top of `command-list.txt` shares some information about what each attribute
> > > > > means; in those help pages, the commands are sorted according to these
> > > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> > > > > diff --git a/Documentation/MyFirstObjectWalk.txt
> > > > > b/Documentation/MyFirstObjectWalk.txt
> > > > > index 2d10eea7a9..fd5bb8fb7d 100644
> > > > > --- a/Documentation/MyFirstObjectWalk.txt
> > > > > +++ b/Documentation/MyFirstObjectWalk.txt
> > > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> > > > > By running your walk with and without the filter, you should find
> > > > > that the total
> > > > > object count in each case is identical. You can also time each invocation of
> > > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm
> > > > > -to yourself the runtime impact of tracking all omitted objects.
> > > > > +to yourself the runtime effect of tracking all omitted objects.
> > > > >
> > > > > === Changing the Order
> > > > >
> > > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> > > > > index 3da4ea98e2..00fcc9d7c7 100644
> > > > > --- a/Documentation/config/pack.txt
> > > > > +++ b/Documentation/config/pack.txt
> > > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> > > > > This cache is used to speed up the writing object phase by not
> > > > > having to recompute the final delta result once the best match
> > > > > for all objects is found. Repacking large repositories on machines
> > > > > - which are tight with memory might be badly impacted by this though,
> > > > > + which are tight with memory might be badly affected by this though,
> > > > > especially if this cache pushes the system into swapping.
> > > > > A value of 0 means no limit. The smallest size of 1 byte may be
> > > > > used to virtually disable this cache. Defaults to 256 MiB.
> > > > > diff --git a/Documentation/git-fast-import.txt
> > > > > b/Documentation/git-fast-import.txt
> > > > > index 39cfa05b28..c6d8e4e1d7 100644
> > > > > --- a/Documentation/git-fast-import.txt
> > > > > +++ b/Documentation/git-fast-import.txt
> > > > > @@ -58,7 +58,7 @@ OPTIONS
> > > > > allowing fast-import to access the filesystem outside of the
> > > > > repository). These options are disabled by default, but can be
> > > > > allowed by providing this option on the command line. This
> > > > > - currently impacts only the `export-marks`, `import-marks`, and
> > > > > + currently affects only the `export-marks`, `import-marks`, and
> > > > > `import-marks-if-exists` feature commands.
> > > > > +
> > > > > Only enable this option if you trust the program generating the
> > > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
> > > > >
> > > > > A `filecopy` command takes effect immediately. Once the source
> > > > > location has been copied to the destination any future commands
> > > > > -applied to the source location will not impact the destination of
> > > > > +applied to the source location will not affect the destination of
> > > > > the copy.
> > > > >
> > > > > `filerename`
> > > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> > > > > A `filerename` command takes effect immediately. Once the source
> > > > > location has been renamed to the destination any future commands
> > > > > applied to the source location will create new files there and not
> > > > > -impact the destination of the rename.
> > > > > +affect the destination of the rename.
> > > > >
> > > > > Note that a `filerename` is the same as a `filecopy` followed by a
> > > > > `filedelete` of the source location. There is a slight performance
> > > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> > > > > to be required).
> > > > > ~~~~~~~~~~
> > > > > Causes fast-import to print the entire `progress` line unmodified to
> > > > > its standard output channel (file descriptor 1) when the command is
> > > > > -processed from the input stream. The command otherwise has no impact
> > > > > +processed from the input stream. The command otherwise has no effect
> > > > > on the current import, or on any of fast-import's internal state.
> > > > >
> > > > > ....
> > > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> > > > > ~~~~~~~~~~
> > > > > Causes fast-import to print the SHA-1 corresponding to a mark to
> > > > > stdout or to the file descriptor previously arranged with the
> > > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the
> > > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the
> > > > > current import; its purpose is to retrieve SHA-1s that later commits
> > > > > might want to refer to in their commit messages.
> > > > >
> > > > > @@ -1050,7 +1050,7 @@ this output safely.
> > > > > ~~~~~~~~~~
> > > > > Causes fast-import to print a blob to a file descriptor previously
> > > > > arranged with the `--cat-blob-fd` argument. The command otherwise
> > > > > -has no impact on the current import; its main purpose is to
> > > > > +has no effect on the current import; its main purpose is to
> > > > > retrieve blobs that may be in fast-import's memory but not
> > > > > accessible from the target repository.
> > > > >
> > > > > @@ -1366,7 +1366,7 @@ code considerably.
> > > > >
> > > > > The branch LRU builtin to fast-import tends to behave very well, and the
> > > > > cost of activating an inactive branch is so low that bouncing around
> > > > > -between branches has virtually no impact on import performance.
> > > > > +between branches has virtually no effect on import performance.
> > > > >
> > > > > Handling Renames
> > > > > ~~~~~~~~~~~~~~~~
> > > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> > > > > index 9067c2079e..01cf3b3d16 100644
> > > > > --- a/Documentation/git-fetch.txt
> > > > > +++ b/Documentation/git-fetch.txt
> > > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> > > > > If left to accumulate, these stale references might make performance
> > > > > worse on big and busy repos that have a lot of branch churn, and
> > > > > e.g. make the output of commands like `git branch -a --contains
> > > > > -<commit>` needlessly verbose, as well as impacting anything else
> > > > > +<commit>` needlessly verbose, as well as affecting anything else
> > > > > that'll work with the complete set of known references.
> > > > >
> > > > > These remote-tracking references can be deleted as a one-off with
> > > > > diff --git a/Documentation/technical/hash-function-transition.txt
> > > > > b/Documentation/technical/hash-function-transition.txt
> > > > > index 7c1630bf83..f4296faffc 100644
> > > > > --- a/Documentation/technical/hash-function-transition.txt
> > > > > +++ b/Documentation/technical/hash-function-transition.txt
> > > > > @@ -42,7 +42,7 @@ mitigations.
> > > > >
> > > > > If SHA-1 and its variants were to be truly broken, Git's hash function
> > > > > could not be considered cryptographically secure any more. This would
> > > > > -impact the communication of hash values because we could not trust
> > > > > +affect the communication of hash values because we could not trust
> > > > > that a given hash value represented the known good version of content
> > > > > that the speaker intended.
> > > > >
> > > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > > > > index fd480b8645..33c60c49d7 100644
> > > > > --- a/Documentation/user-manual.txt
> > > > > +++ b/Documentation/user-manual.txt
> > > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
> > > > >
> > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > changes and commit them, and you can discard any commits you make in this
> > > > > -state without impacting any branches by performing another switch.
> > > > > +state without affecting any branches by performing another switch.
> > > > >
> > > > > If you want to create a new branch to retain commits you create, you may
> > > > > do so (now or later) by using -c with the switch command again. Example:
> > > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> > > > > overwritten by the result of
> > > > > the merge when this combining is done cleanly, or overwritten by a
> > > > > half-merged results when this combining results in conflicts.
> > > > > Therefore, if you have uncommitted changes touching the same files as
> > > > > -the ones impacted by the merge, Git will refuse to proceed. Most of
> > > > > +the ones affected by the merge, Git will refuse to proceed. Most of
> > > > > the time, you will want to commit your changes before you can merge,
> > > > > and if you don't, then linkgit:git-stash[1] can take these changes
> > > > > away while you're doing the merge, and reapply them afterwards.
> > > > > diff --git a/advice.c b/advice.c
> > > > > index 164742305f..9cbbb824a9 100644
> > > > > --- a/advice.c
> > > > > +++ b/advice.c
> > > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> > > > > "\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/builtin/fast-import.c b/builtin/fast-import.c
> > > > > index 3afa81cf9a..24f362d2f4 100644
> > > > > --- a/builtin/fast-import.c
> > > > > +++ b/builtin/fast-import.c
> > > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> > > > > const char *prefix)
> > > > > * We don't parse most options until after we've seen the set of
> > > > > * "feature" lines at the start of the stream (which allows the command
> > > > > * line to override stream data). But we must do an early parse of any
> > > > > - * command-line options that impact how we interpret the feature lines.
> > > > > + * command-line options that affect how we interpret the feature lines.
> > > > > */
> > > > > for (i = 1; i < argc; i++) {
> > > > > const char *arg = argv[i];
> > > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> > > > > index 525c2d8552..749bbca241 100644
> > > > > --- a/builtin/pack-objects.c
> > > > > +++ b/builtin/pack-objects.c
> > > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> > > > > /*
> > > > > * Mark ourselves as active and see if the next step causes
> > > > > * us to cycle to another active object. It's important to do
> > > > > - * this _before_ we loop, because it impacts where we make the
> > > > > + * this _before_ we loop, because it affects where we make the
> > > > > * cut, and thus how our total_depth counter works.
> > > > > * E.g., We may see a partial loop like:
> > > > > *
> > > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> > > > > index f0e80bd7f0..92979ec770 100644
> > > > > --- a/contrib/coccinelle/README
> > > > > +++ b/contrib/coccinelle/README
> > > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:
> > > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.
> > > > >
> > > > > This allows to expose plans of pending large scale refactorings without
> > > > > - impacting the bad pattern checks.
> > > > > + affecting the bad pattern checks.
> > > > > diff --git a/dir.c b/dir.c
> > > > > index 3474e67e8f..235e26a90e 100644
> > > > > --- a/dir.c
> > > > > +++ b/dir.c
> > > > > @@ -2144,7 +2144,7 @@ static enum path_treatment
> > > > > treat_path_fast(struct dir_struct *dir,
> > > > > /*
> > > > > * We get path_recurse in the first run when
> > > > > * directory_exists_in_index() returns index_nonexistent. We
> > > > > - * are sure that new changes in the index does not impact the
> > > > > + * are sure that new changes in the index does not affect the
> > > > > * outcome. Return now.
> > > > > */
> > > > > return path_recurse;
> > > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> > > > > index d0e0e019ea..1fcb98443c 100755
> > > > > --- a/t/perf/p5550-fetch-tags.sh
> > > > > +++ b/t/perf/p5550-fetch-tags.sh
> > > > > @@ -8,7 +8,7 @@ follows.
> > > > >
> > > > > The parent repository has a large number of tags which are disconnected from
> > > > > the rest of history. That makes them candidates for tag-following, but we never
> > > > > -actually grab them (and thus they will impact each subsequent fetch).
> > > > > +actually grab them (and thus they will affect each subsequent fetch).
> > > > >
> > > > > The child repository is a clone of parent, without the tags, and is at least
> > > > > one commit behind the parent (meaning that we will fetch one object and then
> > > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> > > > > index a594b4aa7d..95daba4000 100755
> > > > > --- a/t/t0008-ignores.sh
> > > > > +++ b/t/t0008-ignores.sh
> > > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> > > > > # test standard ignores
> > > > >
> > > > > # First make sure that the presence of a file in the working tree
> > > > > -# does not impact results, but that the presence of a file in the
> > > > > +# does not affect results, but that the presence of a file in the
> > > > > # index does unless the --no-index option is used.
> > > > >
> > > > > for subdir in '' 'a/'
> > > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> > > > > index f028fd1418..a9348f655a 100755
> > > > > --- a/t/t0303-credential-external.sh
> > > > > +++ b/t/t0303-credential-external.sh
> > > > > @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> > > > > eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
> > > > >
> > > > > # clean before the test in case there is cruft left
> > > > > -# over from a previous run that would impact results
> > > > > +# over from a previous run that would affect results
> > > > > helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
> > > > >
> > > > > helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> > > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> > > > > index bc46713a43..568c258c5a 100755
> > > > > --- a/t/t2020-checkout-detach.sh
> > > > > +++ b/t/t2020-checkout-detach.sh
> > > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> > > > > no SHA-1 ellipsis when not as
> > > > >
> > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > changes and commit them, and you can discard any commits you make in this
> > > > > - state without impacting any branches by switching back to a branch.
> > > > > + state without affecting any branches by switching back to a branch.
> > > > >
> > > > > If you want to create a new branch to retain commits you create, you may
> > > > > do so (now or later) by using -c with the switch command. Example:
> > > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> > > > > print SHA-1 ellipsis when asked
> > > > >
> > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > changes and commit them, and you can discard any commits you make in this
> > > > > - state without impacting any branches by switching back to a branch.
> > > > > + state without affecting any branches by switching back to a branch.
> > > > >
> > > > > If you want to create a new branch to retain commits you create, you may
> > > > > do so (now or later) by using -c with the switch command. Example:
> > > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> > > > > index 6cca8b84a6..97365a7786 100755
> > > > > --- a/t/t4013-diff-various.sh
> > > > > +++ b/t/t4013-diff-various.sh
> > > > > @@ -109,7 +109,7 @@ test_expect_success setup '
> > > > > git checkout -f master &&
> > > > >
> > > > > # Same merge as master, but with parents reversed. Hide it in a
> > > > > - # pseudo-ref to avoid impacting tests with --all.
> > > > > + # pseudo-ref to avoid affecting tests with --all.
> > > > > commit=$(echo reverse |
> > > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&
> > > > > git update-ref REVERSE $commit &&
> > > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> > > > > index 7204799a0b..33a6efce2f 100755
> > > > > --- a/t/t5000-tar-tree.sh
> > > > > +++ b/t/t5000-tar-tree.sh
> > > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> > > > > # Pull the size and date of each entry in a tarfile using the system tar.
> > > > > #
> > > > > # We'll pull out only the year from the date; that avoids any question of
> > > > > -# timezones impacting the result (as long as we keep our test times away from a
> > > > > +# timezones affecting the result (as long as we keep our test times away from a
> > > > > # year boundary; our reference times are all in August).
> > > > > #
> > > > > # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> > > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> > > > > index 6348e8d733..ff65f86f50 100644
> > > > > --- a/t/test-lib-functions.sh
> > > > > +++ b/t/test-lib-functions.sh
> > > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> > > > > }
> > > > >
> > > > > # Like "env FOO=BAR some-program", but run inside a subshell, which means
> > > > > -# it also works for shell functions (though those functions cannot impact
> > > > > +# it also works for shell functions (though those functions cannot affect
> > > > > # the environment outside of the test_env invocation).
> > > > > test_env () {
> > > > > (
> > > > > --
> > > > > 2.17.1
> > > > >
> > > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada <varuncvarada@gmail.com> wrote:
> > > > > >
> > > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King <peff@peff.net> wrote:
> > > > > > >
> > > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
> > > > > > >
> > > > > > > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > > > > > > problem the word "impact" in itself is not "jargon".
> > > > > > > >
> > > > > > > > The word means "to have a strong or marked effect on" (v.) and "a
> > > > > > > > strong or market influence" (n.) when used figuratively; it is not
> > > > > > > > synonymous with "affect" and "effect", respectively, as shown even by
> > > > > > > > all of the entries you've cited. Using it as such is the incorrect
> > > > > > > > part, so those are the instances I've changed in the diff.
> > > > > > >
> > > > > > > Er, is that true? From Michal's definitions:
> > > > > > >
> > > > > > > > > From The Collaborative International Dictionary of English v.0.48 :
> > > > > > > > [...]
> > > > > > > > > 2. To affect or influence, especially in a significant or
> > > > > > >
> > > > > > > It literally uses "affect" to define it. The "especially significant"
> > > > > > > does not apply to many, but I don't think that makes it necessarily
> > > > > > > wrong to use impact to mean "affect".
> > > > > >
> > > > > > I was drawing attention to the "especially significant" bit and the
> > > > > > like being there in all the entries. I'm not sure about these
> > > > > > dictionaries, but the definition is hyperbolic / violent / shocking in
> > > > > > every reputable dictionary out there: the Oxford English Dictionary,
> > > > > > Merriam-Webster, and Collins.
> > > > > >
> > > > > > >
> > > > > > > Likewise:
> > > > > > >
> > > > > > > > > From WordNet (r) 3.0 (2006) :
> > > > > > > > [...]
> > > > > > > > > v 1: press or wedge together; pack together
> > > > > > > > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > > > > > > > affect, impact, bear upon, bear on, touch on,
> > > > > > > > > touch]
> > > > > > >
> > > > > > > That is likewise listing "impact" and "affect" as synonyms.
> > > > > > >
> > > > > > > I do agree the word is over-used in some forms of writing, but I don't
> > > > > > > find anything at all confusing or wrong about the uses that you changed
> > > > > > > in your patch. I am a native speaker of English. I'm open to the
> > > > > > > argument that non-native speakers may be more confused by the word. But
> > > > > > > this seems like mostly a style preference thing, and I'd generally
> > > > > > > prefer to leave the contributions and style of the original writers
> > > > > > > intact unless there is a good reason not to.
> > > > > >
> > > > > > I am a native English speaker as well, and there were multiple places
> > > > > > where I had to think twice about what the sentences mean. I agree with
> > > > > > your sentiment about leaving stylistic preferences intact, but this is
> > > > > > actually a semantic one. And given that there is a perfectly good
> > > > > > alternative that doesn't have this confusion / jargon status, I wanted
> > > > > > to make the change to improve it, especially where it says that in the
> > > > > > output of the git command (`git checkout` when in detached HEAD mode).
> > > > > >
> > > > > > >
> > > > > > > Such changes are doubly unwanted in cases like this:
> > > > > > >
> > > > > > > > --- a/compat/nedmalloc/malloc.c.h
> > > > > > > > +++ b/compat/nedmalloc/malloc.c.h
> > > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > > > > > > > #endif /* (FOOTERS && !INSECURE) */
> > > > > > > >
> > > > > > > >
> > > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > > > > > > > #if !INSECURE
> > > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3
> > > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)
> > > > > > >
> > > > > > > where the text is imported from another project, and we'd prefer to stay
> > > > > > > as close to their version as possible (e.g., to avoid unnecessary
> > > > > > > conflicts when pulling in new versions).
> > > > > >
> > > > > > That's fair; I wasn't aware that this was being pulled directly from
> > > > > > another project. I can change this back.
> > > > > >
> > > > > > >
> > > > > > > Also, this one should be "effect" anyway, as it is a noun.
> > > > > >
> > > > > > This seems to have slipped through, as I used a text search tool.
> > > > > >
> > > > > > >
> > > > > > > -Peff
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-30 7:59 ` Michal Suchánek
@ 2021-05-10 17:19 ` Varun Varada
2021-05-10 17:35 ` Michal Suchánek
0 siblings, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-05-10 17:19 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Jeff King, git
On Fri, 30 Apr 2021 at 02:59, Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Thu, Apr 29, 2021 at 08:51:07PM -0500, Varun Varada wrote:
> > On Wed, 28 Apr 2021 at 13:49, Michal Suchánek <msuchanek@suse.de> wrote:
> > >
> > > On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:
> > > > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek <msuchanek@suse.de> wrote:
> > > > >
> > > > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:
> > > > > > Here's the updated diff:
> > > > >
> > > > > As already said multiple general purpose dictionaries recognize '(have)
> > > > > strong effect' as the meaning of 'impact', in some cases even the most
> > > > > common meaning.
> > > >
> > > > There's no contention here. That's the meaning I've been referring to as well.
> > > >
> > > > >
> > > > > In case you have some issue with the word 'jargon' Merriam-Webster gives
> > > > > this definition:
> > > > >
> > > > > 1: the technical terminology or characteristic idiom of a special activity or group
> > > > > 2: obscure and often pretentious language marked by circumlocutions and long words
> > > > > 3a: confused unintelligible language
> > > > > b: a strange, outlandish, or barbarous language or dialect
> > > > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech
> > > > >
> > > > > which the word 'impact' does not fulfill.
> > > > >
> > > > > Further, you would rarely discuss and document an effect that is
> > > > > negligible so in vast majority of cases '(have) strong effect' (ie
> > > > > 'impact') is synonymous to 'affect' and 'affect', respectively.
> > > >
> > > > This is not true, especially in technical contexts. "Affect" doesn't
> > > > mean "has a slight effect on", but simply "has an effect on". This
> > > > suffices in most cases. In cases where one would like to highlight the
> > > > overwhelming/awesome/debilitating/marked/strong effect that something
> > > > has, "impact" can be used. To say that every effect is overwhelming or
> > > > strong is jargon.
> > > >
> > > > >
> > > > > If you can pick out a few places where the use is specifically confusing
> > > > > then please pick out those. Wholesale replacement of one word with
> > > > > another synonym is not desired. It creates useless churn.
> > > >
> > > > I've actually not done a wholesale replacement blindly; the ones I
> > > > replaced are the places where I couldn't find any case where it is
> > > > referring to a "strong/marked effect". This is especially true in the
> > > > negative constructions. If you could help me find places where you
> > > > think the intended meaning is indeed "a strong/marked effect", I can
> > > > remove those from the changes.
> > >
> > > As already pointed out before the mere fact that the author of the text
> > > bothered to document the effect ipmlies that the effect is strong/marked
> > > unless stated otherwise. At any rate 'strong' is always relative. Unless
> > > you have a specific reference of average strenth anything can be
> > > considered strong or weak depending on point of view.
> >
> > This doesn't seem like a plausible or strong argument given the
> > context of the places where I'm editing the text. Most of them are
> > negative constructions, where if one were to assume "strongly affect"
>
> That's not the case. There are some which include negation, and many
> that don't. I did not review all of the patch so can't really tell but
> it looks like the onse that include negation are a minority or about
> half of what you replace at best.
There are 27 changes, 16 of which are negation. That's more than half,
and at least all of these need to be replaced.
>
> > was intended, then that raises the question of what actual effect it
> > will have. The only convincing example of this I can see is the one
> > where it reads "which are tight with memory might be badly impacted by
> > this though". All of the other ones seem like they're binary in
> > whether they will have an effect at all or no, not graduated in terms
> > of the degree of the effect it will have.
>
> Which also means that the distinction between 'strong effect' and
> 'effect' is meaningless, and 'affect' vs 'impact' is synonymous.
> Replacing one with the other is useless churn then.
I'm not sure I understand what you mean by "churn". No one would stop
using Git because of these single-word changes.
As for there being no distinction, there's no gradation within the
semantics of this context; this doesn't change the semantics of the
words themselves. Using "impact" when what is meant is just "effect"
or "affect" is incorrect in all such instances.
>
> Also the cases I saw do not really look confusing in any way so the
> change does not improve the documentation in any way.
Saying "will not impact" means "will not strongly affect", as you've
already agreed. This necessarily means it might affect it, albeit not
strongly. This is confusing to anyone reading the documentation, and
is entirely unnecessary. I don't understand the resistance here for
simple one-word changes that remove this confusion. Am I missing
something?
>
> >
> > >
> > > >
> > > > >
> > > > > You could make a case that 'impact' is significantly less frequent word
> > > > > compared to effect/affect and thus makes the text harder to understand
> > > > > for non-native speakers. However, that's not the point you brought up,
> > > > > and even then it is very weak point to make, especially without any
> > > > > actual source for the frequency data. You could also counter that all of
> > > > > these are common loanwords in many languages and are thus easy to
> > > > > understand to non-native speakers anyway.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Michal
> > > > > >
> > > > > > Documentation/MyFirstContribution.txt | 2 +-
> > > > > > Documentation/MyFirstObjectWalk.txt | 2 +-
> > > > > > Documentation/config/pack.txt | 2 +-
> > > > > > Documentation/git-fast-import.txt | 14 +++++++-------
> > > > > > Documentation/git-fetch.txt | 2 +-
> > > > > > .../technical/hash-function-transition.txt | 2 +-
> > > > > > Documentation/user-manual.txt | 4 ++--
> > > > > > advice.c | 2 +-
> > > > > > builtin/fast-import.c | 2 +-
> > > > > > builtin/pack-objects.c | 2 +-
> > > > > > contrib/coccinelle/README | 2 +-
> > > > > > dir.c | 2 +-
> > > > > > t/perf/p5550-fetch-tags.sh | 2 +-
> > > > > > t/t0008-ignores.sh | 2 +-
> > > > > > t/t0303-credential-external.sh | 2 +-
> > > > > > t/t2020-checkout-detach.sh | 4 ++--
> > > > > > t/t4013-diff-various.sh | 2 +-
> > > > > > t/t5000-tar-tree.sh | 2 +-
> > > > > > t/test-lib-functions.sh | 2 +-
> > > > > > 19 files changed, 27 insertions(+), 27 deletions(-)
> > > > > >
> > > > > > diff --git a/Documentation/MyFirstContribution.txt
> > > > > > b/Documentation/MyFirstContribution.txt
> > > > > > index af0a9da62e..8372a7e59e 100644
> > > > > > --- a/Documentation/MyFirstContribution.txt
> > > > > > +++ b/Documentation/MyFirstContribution.txt
> > > > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> > > > > > how to show it in the general
> > > > > > command list shown by `git help git` or `git help -a`, which is generated from
> > > > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> > > > > > line above it in alphabetical order. Now, we can add some attributes about the
> > > > > > -command which impacts where it shows up in the aforementioned help
> > > > > > commands. The
> > > > > > +command which affects where it shows up in the aforementioned help
> > > > > > commands. The
> > > > > > top of `command-list.txt` shares some information about what each attribute
> > > > > > means; in those help pages, the commands are sorted according to these
> > > > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> > > > > > diff --git a/Documentation/MyFirstObjectWalk.txt
> > > > > > b/Documentation/MyFirstObjectWalk.txt
> > > > > > index 2d10eea7a9..fd5bb8fb7d 100644
> > > > > > --- a/Documentation/MyFirstObjectWalk.txt
> > > > > > +++ b/Documentation/MyFirstObjectWalk.txt
> > > > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> > > > > > By running your walk with and without the filter, you should find
> > > > > > that the total
> > > > > > object count in each case is identical. You can also time each invocation of
> > > > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm
> > > > > > -to yourself the runtime impact of tracking all omitted objects.
> > > > > > +to yourself the runtime effect of tracking all omitted objects.
> > > > > >
> > > > > > === Changing the Order
> > > > > >
> > > > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> > > > > > index 3da4ea98e2..00fcc9d7c7 100644
> > > > > > --- a/Documentation/config/pack.txt
> > > > > > +++ b/Documentation/config/pack.txt
> > > > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> > > > > > This cache is used to speed up the writing object phase by not
> > > > > > having to recompute the final delta result once the best match
> > > > > > for all objects is found. Repacking large repositories on machines
> > > > > > - which are tight with memory might be badly impacted by this though,
> > > > > > + which are tight with memory might be badly affected by this though,
> > > > > > especially if this cache pushes the system into swapping.
> > > > > > A value of 0 means no limit. The smallest size of 1 byte may be
> > > > > > used to virtually disable this cache. Defaults to 256 MiB.
> > > > > > diff --git a/Documentation/git-fast-import.txt
> > > > > > b/Documentation/git-fast-import.txt
> > > > > > index 39cfa05b28..c6d8e4e1d7 100644
> > > > > > --- a/Documentation/git-fast-import.txt
> > > > > > +++ b/Documentation/git-fast-import.txt
> > > > > > @@ -58,7 +58,7 @@ OPTIONS
> > > > > > allowing fast-import to access the filesystem outside of the
> > > > > > repository). These options are disabled by default, but can be
> > > > > > allowed by providing this option on the command line. This
> > > > > > - currently impacts only the `export-marks`, `import-marks`, and
> > > > > > + currently affects only the `export-marks`, `import-marks`, and
> > > > > > `import-marks-if-exists` feature commands.
> > > > > > +
> > > > > > Only enable this option if you trust the program generating the
> > > > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
> > > > > >
> > > > > > A `filecopy` command takes effect immediately. Once the source
> > > > > > location has been copied to the destination any future commands
> > > > > > -applied to the source location will not impact the destination of
> > > > > > +applied to the source location will not affect the destination of
> > > > > > the copy.
> > > > > >
> > > > > > `filerename`
> > > > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> > > > > > A `filerename` command takes effect immediately. Once the source
> > > > > > location has been renamed to the destination any future commands
> > > > > > applied to the source location will create new files there and not
> > > > > > -impact the destination of the rename.
> > > > > > +affect the destination of the rename.
> > > > > >
> > > > > > Note that a `filerename` is the same as a `filecopy` followed by a
> > > > > > `filedelete` of the source location. There is a slight performance
> > > > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> > > > > > to be required).
> > > > > > ~~~~~~~~~~
> > > > > > Causes fast-import to print the entire `progress` line unmodified to
> > > > > > its standard output channel (file descriptor 1) when the command is
> > > > > > -processed from the input stream. The command otherwise has no impact
> > > > > > +processed from the input stream. The command otherwise has no effect
> > > > > > on the current import, or on any of fast-import's internal state.
> > > > > >
> > > > > > ....
> > > > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> > > > > > ~~~~~~~~~~
> > > > > > Causes fast-import to print the SHA-1 corresponding to a mark to
> > > > > > stdout or to the file descriptor previously arranged with the
> > > > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the
> > > > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the
> > > > > > current import; its purpose is to retrieve SHA-1s that later commits
> > > > > > might want to refer to in their commit messages.
> > > > > >
> > > > > > @@ -1050,7 +1050,7 @@ this output safely.
> > > > > > ~~~~~~~~~~
> > > > > > Causes fast-import to print a blob to a file descriptor previously
> > > > > > arranged with the `--cat-blob-fd` argument. The command otherwise
> > > > > > -has no impact on the current import; its main purpose is to
> > > > > > +has no effect on the current import; its main purpose is to
> > > > > > retrieve blobs that may be in fast-import's memory but not
> > > > > > accessible from the target repository.
> > > > > >
> > > > > > @@ -1366,7 +1366,7 @@ code considerably.
> > > > > >
> > > > > > The branch LRU builtin to fast-import tends to behave very well, and the
> > > > > > cost of activating an inactive branch is so low that bouncing around
> > > > > > -between branches has virtually no impact on import performance.
> > > > > > +between branches has virtually no effect on import performance.
> > > > > >
> > > > > > Handling Renames
> > > > > > ~~~~~~~~~~~~~~~~
> > > > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> > > > > > index 9067c2079e..01cf3b3d16 100644
> > > > > > --- a/Documentation/git-fetch.txt
> > > > > > +++ b/Documentation/git-fetch.txt
> > > > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> > > > > > If left to accumulate, these stale references might make performance
> > > > > > worse on big and busy repos that have a lot of branch churn, and
> > > > > > e.g. make the output of commands like `git branch -a --contains
> > > > > > -<commit>` needlessly verbose, as well as impacting anything else
> > > > > > +<commit>` needlessly verbose, as well as affecting anything else
> > > > > > that'll work with the complete set of known references.
> > > > > >
> > > > > > These remote-tracking references can be deleted as a one-off with
> > > > > > diff --git a/Documentation/technical/hash-function-transition.txt
> > > > > > b/Documentation/technical/hash-function-transition.txt
> > > > > > index 7c1630bf83..f4296faffc 100644
> > > > > > --- a/Documentation/technical/hash-function-transition.txt
> > > > > > +++ b/Documentation/technical/hash-function-transition.txt
> > > > > > @@ -42,7 +42,7 @@ mitigations.
> > > > > >
> > > > > > If SHA-1 and its variants were to be truly broken, Git's hash function
> > > > > > could not be considered cryptographically secure any more. This would
> > > > > > -impact the communication of hash values because we could not trust
> > > > > > +affect the communication of hash values because we could not trust
> > > > > > that a given hash value represented the known good version of content
> > > > > > that the speaker intended.
> > > > > >
> > > > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > > > > > index fd480b8645..33c60c49d7 100644
> > > > > > --- a/Documentation/user-manual.txt
> > > > > > +++ b/Documentation/user-manual.txt
> > > > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
> > > > > >
> > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > -state without impacting any branches by performing another switch.
> > > > > > +state without affecting any branches by performing another switch.
> > > > > >
> > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > do so (now or later) by using -c with the switch command again. Example:
> > > > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> > > > > > overwritten by the result of
> > > > > > the merge when this combining is done cleanly, or overwritten by a
> > > > > > half-merged results when this combining results in conflicts.
> > > > > > Therefore, if you have uncommitted changes touching the same files as
> > > > > > -the ones impacted by the merge, Git will refuse to proceed. Most of
> > > > > > +the ones affected by the merge, Git will refuse to proceed. Most of
> > > > > > the time, you will want to commit your changes before you can merge,
> > > > > > and if you don't, then linkgit:git-stash[1] can take these changes
> > > > > > away while you're doing the merge, and reapply them afterwards.
> > > > > > diff --git a/advice.c b/advice.c
> > > > > > index 164742305f..9cbbb824a9 100644
> > > > > > --- a/advice.c
> > > > > > +++ b/advice.c
> > > > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> > > > > > "\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/builtin/fast-import.c b/builtin/fast-import.c
> > > > > > index 3afa81cf9a..24f362d2f4 100644
> > > > > > --- a/builtin/fast-import.c
> > > > > > +++ b/builtin/fast-import.c
> > > > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> > > > > > const char *prefix)
> > > > > > * We don't parse most options until after we've seen the set of
> > > > > > * "feature" lines at the start of the stream (which allows the command
> > > > > > * line to override stream data). But we must do an early parse of any
> > > > > > - * command-line options that impact how we interpret the feature lines.
> > > > > > + * command-line options that affect how we interpret the feature lines.
> > > > > > */
> > > > > > for (i = 1; i < argc; i++) {
> > > > > > const char *arg = argv[i];
> > > > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> > > > > > index 525c2d8552..749bbca241 100644
> > > > > > --- a/builtin/pack-objects.c
> > > > > > +++ b/builtin/pack-objects.c
> > > > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> > > > > > /*
> > > > > > * Mark ourselves as active and see if the next step causes
> > > > > > * us to cycle to another active object. It's important to do
> > > > > > - * this _before_ we loop, because it impacts where we make the
> > > > > > + * this _before_ we loop, because it affects where we make the
> > > > > > * cut, and thus how our total_depth counter works.
> > > > > > * E.g., We may see a partial loop like:
> > > > > > *
> > > > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> > > > > > index f0e80bd7f0..92979ec770 100644
> > > > > > --- a/contrib/coccinelle/README
> > > > > > +++ b/contrib/coccinelle/README
> > > > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:
> > > > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.
> > > > > >
> > > > > > This allows to expose plans of pending large scale refactorings without
> > > > > > - impacting the bad pattern checks.
> > > > > > + affecting the bad pattern checks.
> > > > > > diff --git a/dir.c b/dir.c
> > > > > > index 3474e67e8f..235e26a90e 100644
> > > > > > --- a/dir.c
> > > > > > +++ b/dir.c
> > > > > > @@ -2144,7 +2144,7 @@ static enum path_treatment
> > > > > > treat_path_fast(struct dir_struct *dir,
> > > > > > /*
> > > > > > * We get path_recurse in the first run when
> > > > > > * directory_exists_in_index() returns index_nonexistent. We
> > > > > > - * are sure that new changes in the index does not impact the
> > > > > > + * are sure that new changes in the index does not affect the
> > > > > > * outcome. Return now.
> > > > > > */
> > > > > > return path_recurse;
> > > > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> > > > > > index d0e0e019ea..1fcb98443c 100755
> > > > > > --- a/t/perf/p5550-fetch-tags.sh
> > > > > > +++ b/t/perf/p5550-fetch-tags.sh
> > > > > > @@ -8,7 +8,7 @@ follows.
> > > > > >
> > > > > > The parent repository has a large number of tags which are disconnected from
> > > > > > the rest of history. That makes them candidates for tag-following, but we never
> > > > > > -actually grab them (and thus they will impact each subsequent fetch).
> > > > > > +actually grab them (and thus they will affect each subsequent fetch).
> > > > > >
> > > > > > The child repository is a clone of parent, without the tags, and is at least
> > > > > > one commit behind the parent (meaning that we will fetch one object and then
> > > > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> > > > > > index a594b4aa7d..95daba4000 100755
> > > > > > --- a/t/t0008-ignores.sh
> > > > > > +++ b/t/t0008-ignores.sh
> > > > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> > > > > > # test standard ignores
> > > > > >
> > > > > > # First make sure that the presence of a file in the working tree
> > > > > > -# does not impact results, but that the presence of a file in the
> > > > > > +# does not affect results, but that the presence of a file in the
> > > > > > # index does unless the --no-index option is used.
> > > > > >
> > > > > > for subdir in '' 'a/'
> > > > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> > > > > > index f028fd1418..a9348f655a 100755
> > > > > > --- a/t/t0303-credential-external.sh
> > > > > > +++ b/t/t0303-credential-external.sh
> > > > > > @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> > > > > > eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
> > > > > >
> > > > > > # clean before the test in case there is cruft left
> > > > > > -# over from a previous run that would impact results
> > > > > > +# over from a previous run that would affect results
> > > > > > helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
> > > > > >
> > > > > > helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> > > > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> > > > > > index bc46713a43..568c258c5a 100755
> > > > > > --- a/t/t2020-checkout-detach.sh
> > > > > > +++ b/t/t2020-checkout-detach.sh
> > > > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> > > > > > no SHA-1 ellipsis when not as
> > > > > >
> > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > - state without impacting any branches by switching back to a branch.
> > > > > > + state without affecting any branches by switching back to a branch.
> > > > > >
> > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > do so (now or later) by using -c with the switch command. Example:
> > > > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> > > > > > print SHA-1 ellipsis when asked
> > > > > >
> > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > - state without impacting any branches by switching back to a branch.
> > > > > > + state without affecting any branches by switching back to a branch.
> > > > > >
> > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > do so (now or later) by using -c with the switch command. Example:
> > > > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> > > > > > index 6cca8b84a6..97365a7786 100755
> > > > > > --- a/t/t4013-diff-various.sh
> > > > > > +++ b/t/t4013-diff-various.sh
> > > > > > @@ -109,7 +109,7 @@ test_expect_success setup '
> > > > > > git checkout -f master &&
> > > > > >
> > > > > > # Same merge as master, but with parents reversed. Hide it in a
> > > > > > - # pseudo-ref to avoid impacting tests with --all.
> > > > > > + # pseudo-ref to avoid affecting tests with --all.
> > > > > > commit=$(echo reverse |
> > > > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&
> > > > > > git update-ref REVERSE $commit &&
> > > > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> > > > > > index 7204799a0b..33a6efce2f 100755
> > > > > > --- a/t/t5000-tar-tree.sh
> > > > > > +++ b/t/t5000-tar-tree.sh
> > > > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> > > > > > # Pull the size and date of each entry in a tarfile using the system tar.
> > > > > > #
> > > > > > # We'll pull out only the year from the date; that avoids any question of
> > > > > > -# timezones impacting the result (as long as we keep our test times away from a
> > > > > > +# timezones affecting the result (as long as we keep our test times away from a
> > > > > > # year boundary; our reference times are all in August).
> > > > > > #
> > > > > > # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> > > > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> > > > > > index 6348e8d733..ff65f86f50 100644
> > > > > > --- a/t/test-lib-functions.sh
> > > > > > +++ b/t/test-lib-functions.sh
> > > > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> > > > > > }
> > > > > >
> > > > > > # Like "env FOO=BAR some-program", but run inside a subshell, which means
> > > > > > -# it also works for shell functions (though those functions cannot impact
> > > > > > +# it also works for shell functions (though those functions cannot affect
> > > > > > # the environment outside of the test_env invocation).
> > > > > > test_env () {
> > > > > > (
> > > > > > --
> > > > > > 2.17.1
> > > > > >
> > > > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada <varuncvarada@gmail.com> wrote:
> > > > > > >
> > > > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King <peff@peff.net> wrote:
> > > > > > > >
> > > > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
> > > > > > > >
> > > > > > > > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > > > > > > > problem the word "impact" in itself is not "jargon".
> > > > > > > > >
> > > > > > > > > The word means "to have a strong or marked effect on" (v.) and "a
> > > > > > > > > strong or market influence" (n.) when used figuratively; it is not
> > > > > > > > > synonymous with "affect" and "effect", respectively, as shown even by
> > > > > > > > > all of the entries you've cited. Using it as such is the incorrect
> > > > > > > > > part, so those are the instances I've changed in the diff.
> > > > > > > >
> > > > > > > > Er, is that true? From Michal's definitions:
> > > > > > > >
> > > > > > > > > > From The Collaborative International Dictionary of English v.0.48 :
> > > > > > > > > [...]
> > > > > > > > > > 2. To affect or influence, especially in a significant or
> > > > > > > >
> > > > > > > > It literally uses "affect" to define it. The "especially significant"
> > > > > > > > does not apply to many, but I don't think that makes it necessarily
> > > > > > > > wrong to use impact to mean "affect".
> > > > > > >
> > > > > > > I was drawing attention to the "especially significant" bit and the
> > > > > > > like being there in all the entries. I'm not sure about these
> > > > > > > dictionaries, but the definition is hyperbolic / violent / shocking in
> > > > > > > every reputable dictionary out there: the Oxford English Dictionary,
> > > > > > > Merriam-Webster, and Collins.
> > > > > > >
> > > > > > > >
> > > > > > > > Likewise:
> > > > > > > >
> > > > > > > > > > From WordNet (r) 3.0 (2006) :
> > > > > > > > > [...]
> > > > > > > > > > v 1: press or wedge together; pack together
> > > > > > > > > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > > > > > > > > affect, impact, bear upon, bear on, touch on,
> > > > > > > > > > touch]
> > > > > > > >
> > > > > > > > That is likewise listing "impact" and "affect" as synonyms.
> > > > > > > >
> > > > > > > > I do agree the word is over-used in some forms of writing, but I don't
> > > > > > > > find anything at all confusing or wrong about the uses that you changed
> > > > > > > > in your patch. I am a native speaker of English. I'm open to the
> > > > > > > > argument that non-native speakers may be more confused by the word. But
> > > > > > > > this seems like mostly a style preference thing, and I'd generally
> > > > > > > > prefer to leave the contributions and style of the original writers
> > > > > > > > intact unless there is a good reason not to.
> > > > > > >
> > > > > > > I am a native English speaker as well, and there were multiple places
> > > > > > > where I had to think twice about what the sentences mean. I agree with
> > > > > > > your sentiment about leaving stylistic preferences intact, but this is
> > > > > > > actually a semantic one. And given that there is a perfectly good
> > > > > > > alternative that doesn't have this confusion / jargon status, I wanted
> > > > > > > to make the change to improve it, especially where it says that in the
> > > > > > > output of the git command (`git checkout` when in detached HEAD mode).
> > > > > > >
> > > > > > > >
> > > > > > > > Such changes are doubly unwanted in cases like this:
> > > > > > > >
> > > > > > > > > --- a/compat/nedmalloc/malloc.c.h
> > > > > > > > > +++ b/compat/nedmalloc/malloc.c.h
> > > > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > > > > > > > > #endif /* (FOOTERS && !INSECURE) */
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > > > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > > > > > > > > #if !INSECURE
> > > > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3
> > > > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)
> > > > > > > >
> > > > > > > > where the text is imported from another project, and we'd prefer to stay
> > > > > > > > as close to their version as possible (e.g., to avoid unnecessary
> > > > > > > > conflicts when pulling in new versions).
> > > > > > >
> > > > > > > That's fair; I wasn't aware that this was being pulled directly from
> > > > > > > another project. I can change this back.
> > > > > > >
> > > > > > > >
> > > > > > > > Also, this one should be "effect" anyway, as it is a noun.
> > > > > > >
> > > > > > > This seems to have slipped through, as I used a text search tool.
> > > > > > >
> > > > > > > >
> > > > > > > > -Peff
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-10 17:19 ` Varun Varada
@ 2021-05-10 17:35 ` Michal Suchánek
2021-05-10 18:37 ` Varun Varada
2021-05-12 2:48 ` Felipe Contreras
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-05-10 17:35 UTC (permalink / raw)
To: Varun Varada; +Cc: Jeff King, git
On Mon, May 10, 2021 at 12:19:05PM -0500, Varun Varada wrote:
> On Fri, 30 Apr 2021 at 02:59, Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > On Thu, Apr 29, 2021 at 08:51:07PM -0500, Varun Varada wrote:
> > > On Wed, 28 Apr 2021 at 13:49, Michal Suchánek <msuchanek@suse.de> wrote:
> > > >
> > > > On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:
> > > > > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek <msuchanek@suse.de> wrote:
> > > > > >
> > > > > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:
> > > > > > > Here's the updated diff:
> > > > > >
> > > > > > As already said multiple general purpose dictionaries recognize '(have)
> > > > > > strong effect' as the meaning of 'impact', in some cases even the most
> > > > > > common meaning.
> > > > >
> > > > > There's no contention here. That's the meaning I've been referring to as well.
> > > > >
> > > > > >
> > > > > > In case you have some issue with the word 'jargon' Merriam-Webster gives
> > > > > > this definition:
> > > > > >
> > > > > > 1: the technical terminology or characteristic idiom of a special activity or group
> > > > > > 2: obscure and often pretentious language marked by circumlocutions and long words
> > > > > > 3a: confused unintelligible language
> > > > > > b: a strange, outlandish, or barbarous language or dialect
> > > > > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech
> > > > > >
> > > > > > which the word 'impact' does not fulfill.
> > > > > >
> > > > > > Further, you would rarely discuss and document an effect that is
> > > > > > negligible so in vast majority of cases '(have) strong effect' (ie
> > > > > > 'impact') is synonymous to 'affect' and 'affect', respectively.
> > > > >
> > > > > This is not true, especially in technical contexts. "Affect" doesn't
> > > > > mean "has a slight effect on", but simply "has an effect on". This
> > > > > suffices in most cases. In cases where one would like to highlight the
> > > > > overwhelming/awesome/debilitating/marked/strong effect that something
> > > > > has, "impact" can be used. To say that every effect is overwhelming or
> > > > > strong is jargon.
> > > > >
> > > > > >
> > > > > > If you can pick out a few places where the use is specifically confusing
> > > > > > then please pick out those. Wholesale replacement of one word with
> > > > > > another synonym is not desired. It creates useless churn.
> > > > >
> > > > > I've actually not done a wholesale replacement blindly; the ones I
> > > > > replaced are the places where I couldn't find any case where it is
> > > > > referring to a "strong/marked effect". This is especially true in the
> > > > > negative constructions. If you could help me find places where you
> > > > > think the intended meaning is indeed "a strong/marked effect", I can
> > > > > remove those from the changes.
> > > >
> > > > As already pointed out before the mere fact that the author of the text
> > > > bothered to document the effect ipmlies that the effect is strong/marked
> > > > unless stated otherwise. At any rate 'strong' is always relative. Unless
> > > > you have a specific reference of average strenth anything can be
> > > > considered strong or weak depending on point of view.
> > >
> > > This doesn't seem like a plausible or strong argument given the
> > > context of the places where I'm editing the text. Most of them are
> > > negative constructions, where if one were to assume "strongly affect"
> >
> > That's not the case. There are some which include negation, and many
> > that don't. I did not review all of the patch so can't really tell but
> > it looks like the onse that include negation are a minority or about
> > half of what you replace at best.
>
> There are 27 changes, 16 of which are negation. That's more than half,
> and at least all of these need to be replaced.
>
> >
> > > was intended, then that raises the question of what actual effect it
> > > will have. The only convincing example of this I can see is the one
> > > where it reads "which are tight with memory might be badly impacted by
> > > this though". All of the other ones seem like they're binary in
> > > whether they will have an effect at all or no, not graduated in terms
> > > of the degree of the effect it will have.
> >
> > Which also means that the distinction between 'strong effect' and
> > 'effect' is meaningless, and 'affect' vs 'impact' is synonymous.
> > Replacing one with the other is useless churn then.
>
> I'm not sure I understand what you mean by "churn". No one would stop
> using Git because of these single-word changes.
It refers to redundant changes to the codebase which do not improve it in
any way.
>
> As for there being no distinction, there's no gradation within the
> semantics of this context; this doesn't change the semantics of the
> words themselves. Using "impact" when what is meant is just "effect"
> or "affect" is incorrect in all such instances.
That's your opinion not shared by the authors of the text.
The authority you refer to is MIT which is known for technical
brilliance but not as authority on linguistics.
>
> >
> > Also the cases I saw do not really look confusing in any way so the
> > change does not improve the documentation in any way.
>
> Saying "will not impact" means "will not strongly affect", as you've
> already agreed. This necessarily means it might affect it, albeit not
> strongly.
Or not at all.
> This is confusing to anyone reading the documentation, and
When the distinction is not meaningful it is not really confusing in
this use, either.
> is entirely unnecessary.
Also you did not limit your patch to these cases that you say are
confusing.
> I don't understand the resistance here for
> simple one-word changes that remove this confusion. Am I missing
> something?
There does not seem to be any confusion to remove, at least you have not
pointed out any specific case that is particularly confusing.
If you do wholesale word replacement in the project for no good reason
it only makes working with the project history harder.
Thanks
Michal
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > You could make a case that 'impact' is significantly less frequent word
> > > > > > compared to effect/affect and thus makes the text harder to understand
> > > > > > for non-native speakers. However, that's not the point you brought up,
> > > > > > and even then it is very weak point to make, especially without any
> > > > > > actual source for the frequency data. You could also counter that all of
> > > > > > these are common loanwords in many languages and are thus easy to
> > > > > > understand to non-native speakers anyway.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Michal
> > > > > > >
> > > > > > > Documentation/MyFirstContribution.txt | 2 +-
> > > > > > > Documentation/MyFirstObjectWalk.txt | 2 +-
> > > > > > > Documentation/config/pack.txt | 2 +-
> > > > > > > Documentation/git-fast-import.txt | 14 +++++++-------
> > > > > > > Documentation/git-fetch.txt | 2 +-
> > > > > > > .../technical/hash-function-transition.txt | 2 +-
> > > > > > > Documentation/user-manual.txt | 4 ++--
> > > > > > > advice.c | 2 +-
> > > > > > > builtin/fast-import.c | 2 +-
> > > > > > > builtin/pack-objects.c | 2 +-
> > > > > > > contrib/coccinelle/README | 2 +-
> > > > > > > dir.c | 2 +-
> > > > > > > t/perf/p5550-fetch-tags.sh | 2 +-
> > > > > > > t/t0008-ignores.sh | 2 +-
> > > > > > > t/t0303-credential-external.sh | 2 +-
> > > > > > > t/t2020-checkout-detach.sh | 4 ++--
> > > > > > > t/t4013-diff-various.sh | 2 +-
> > > > > > > t/t5000-tar-tree.sh | 2 +-
> > > > > > > t/test-lib-functions.sh | 2 +-
> > > > > > > 19 files changed, 27 insertions(+), 27 deletions(-)
> > > > > > >
> > > > > > > diff --git a/Documentation/MyFirstContribution.txt
> > > > > > > b/Documentation/MyFirstContribution.txt
> > > > > > > index af0a9da62e..8372a7e59e 100644
> > > > > > > --- a/Documentation/MyFirstContribution.txt
> > > > > > > +++ b/Documentation/MyFirstContribution.txt
> > > > > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> > > > > > > how to show it in the general
> > > > > > > command list shown by `git help git` or `git help -a`, which is generated from
> > > > > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> > > > > > > line above it in alphabetical order. Now, we can add some attributes about the
> > > > > > > -command which impacts where it shows up in the aforementioned help
> > > > > > > commands. The
> > > > > > > +command which affects where it shows up in the aforementioned help
> > > > > > > commands. The
> > > > > > > top of `command-list.txt` shares some information about what each attribute
> > > > > > > means; in those help pages, the commands are sorted according to these
> > > > > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> > > > > > > diff --git a/Documentation/MyFirstObjectWalk.txt
> > > > > > > b/Documentation/MyFirstObjectWalk.txt
> > > > > > > index 2d10eea7a9..fd5bb8fb7d 100644
> > > > > > > --- a/Documentation/MyFirstObjectWalk.txt
> > > > > > > +++ b/Documentation/MyFirstObjectWalk.txt
> > > > > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> > > > > > > By running your walk with and without the filter, you should find
> > > > > > > that the total
> > > > > > > object count in each case is identical. You can also time each invocation of
> > > > > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm
> > > > > > > -to yourself the runtime impact of tracking all omitted objects.
> > > > > > > +to yourself the runtime effect of tracking all omitted objects.
> > > > > > >
> > > > > > > === Changing the Order
> > > > > > >
> > > > > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> > > > > > > index 3da4ea98e2..00fcc9d7c7 100644
> > > > > > > --- a/Documentation/config/pack.txt
> > > > > > > +++ b/Documentation/config/pack.txt
> > > > > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> > > > > > > This cache is used to speed up the writing object phase by not
> > > > > > > having to recompute the final delta result once the best match
> > > > > > > for all objects is found. Repacking large repositories on machines
> > > > > > > - which are tight with memory might be badly impacted by this though,
> > > > > > > + which are tight with memory might be badly affected by this though,
> > > > > > > especially if this cache pushes the system into swapping.
> > > > > > > A value of 0 means no limit. The smallest size of 1 byte may be
> > > > > > > used to virtually disable this cache. Defaults to 256 MiB.
> > > > > > > diff --git a/Documentation/git-fast-import.txt
> > > > > > > b/Documentation/git-fast-import.txt
> > > > > > > index 39cfa05b28..c6d8e4e1d7 100644
> > > > > > > --- a/Documentation/git-fast-import.txt
> > > > > > > +++ b/Documentation/git-fast-import.txt
> > > > > > > @@ -58,7 +58,7 @@ OPTIONS
> > > > > > > allowing fast-import to access the filesystem outside of the
> > > > > > > repository). These options are disabled by default, but can be
> > > > > > > allowed by providing this option on the command line. This
> > > > > > > - currently impacts only the `export-marks`, `import-marks`, and
> > > > > > > + currently affects only the `export-marks`, `import-marks`, and
> > > > > > > `import-marks-if-exists` feature commands.
> > > > > > > +
> > > > > > > Only enable this option if you trust the program generating the
> > > > > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
> > > > > > >
> > > > > > > A `filecopy` command takes effect immediately. Once the source
> > > > > > > location has been copied to the destination any future commands
> > > > > > > -applied to the source location will not impact the destination of
> > > > > > > +applied to the source location will not affect the destination of
> > > > > > > the copy.
> > > > > > >
> > > > > > > `filerename`
> > > > > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> > > > > > > A `filerename` command takes effect immediately. Once the source
> > > > > > > location has been renamed to the destination any future commands
> > > > > > > applied to the source location will create new files there and not
> > > > > > > -impact the destination of the rename.
> > > > > > > +affect the destination of the rename.
> > > > > > >
> > > > > > > Note that a `filerename` is the same as a `filecopy` followed by a
> > > > > > > `filedelete` of the source location. There is a slight performance
> > > > > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> > > > > > > to be required).
> > > > > > > ~~~~~~~~~~
> > > > > > > Causes fast-import to print the entire `progress` line unmodified to
> > > > > > > its standard output channel (file descriptor 1) when the command is
> > > > > > > -processed from the input stream. The command otherwise has no impact
> > > > > > > +processed from the input stream. The command otherwise has no effect
> > > > > > > on the current import, or on any of fast-import's internal state.
> > > > > > >
> > > > > > > ....
> > > > > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> > > > > > > ~~~~~~~~~~
> > > > > > > Causes fast-import to print the SHA-1 corresponding to a mark to
> > > > > > > stdout or to the file descriptor previously arranged with the
> > > > > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the
> > > > > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the
> > > > > > > current import; its purpose is to retrieve SHA-1s that later commits
> > > > > > > might want to refer to in their commit messages.
> > > > > > >
> > > > > > > @@ -1050,7 +1050,7 @@ this output safely.
> > > > > > > ~~~~~~~~~~
> > > > > > > Causes fast-import to print a blob to a file descriptor previously
> > > > > > > arranged with the `--cat-blob-fd` argument. The command otherwise
> > > > > > > -has no impact on the current import; its main purpose is to
> > > > > > > +has no effect on the current import; its main purpose is to
> > > > > > > retrieve blobs that may be in fast-import's memory but not
> > > > > > > accessible from the target repository.
> > > > > > >
> > > > > > > @@ -1366,7 +1366,7 @@ code considerably.
> > > > > > >
> > > > > > > The branch LRU builtin to fast-import tends to behave very well, and the
> > > > > > > cost of activating an inactive branch is so low that bouncing around
> > > > > > > -between branches has virtually no impact on import performance.
> > > > > > > +between branches has virtually no effect on import performance.
> > > > > > >
> > > > > > > Handling Renames
> > > > > > > ~~~~~~~~~~~~~~~~
> > > > > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> > > > > > > index 9067c2079e..01cf3b3d16 100644
> > > > > > > --- a/Documentation/git-fetch.txt
> > > > > > > +++ b/Documentation/git-fetch.txt
> > > > > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> > > > > > > If left to accumulate, these stale references might make performance
> > > > > > > worse on big and busy repos that have a lot of branch churn, and
> > > > > > > e.g. make the output of commands like `git branch -a --contains
> > > > > > > -<commit>` needlessly verbose, as well as impacting anything else
> > > > > > > +<commit>` needlessly verbose, as well as affecting anything else
> > > > > > > that'll work with the complete set of known references.
> > > > > > >
> > > > > > > These remote-tracking references can be deleted as a one-off with
> > > > > > > diff --git a/Documentation/technical/hash-function-transition.txt
> > > > > > > b/Documentation/technical/hash-function-transition.txt
> > > > > > > index 7c1630bf83..f4296faffc 100644
> > > > > > > --- a/Documentation/technical/hash-function-transition.txt
> > > > > > > +++ b/Documentation/technical/hash-function-transition.txt
> > > > > > > @@ -42,7 +42,7 @@ mitigations.
> > > > > > >
> > > > > > > If SHA-1 and its variants were to be truly broken, Git's hash function
> > > > > > > could not be considered cryptographically secure any more. This would
> > > > > > > -impact the communication of hash values because we could not trust
> > > > > > > +affect the communication of hash values because we could not trust
> > > > > > > that a given hash value represented the known good version of content
> > > > > > > that the speaker intended.
> > > > > > >
> > > > > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > > > > > > index fd480b8645..33c60c49d7 100644
> > > > > > > --- a/Documentation/user-manual.txt
> > > > > > > +++ b/Documentation/user-manual.txt
> > > > > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
> > > > > > >
> > > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > > -state without impacting any branches by performing another switch.
> > > > > > > +state without affecting any branches by performing another switch.
> > > > > > >
> > > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > > do so (now or later) by using -c with the switch command again. Example:
> > > > > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> > > > > > > overwritten by the result of
> > > > > > > the merge when this combining is done cleanly, or overwritten by a
> > > > > > > half-merged results when this combining results in conflicts.
> > > > > > > Therefore, if you have uncommitted changes touching the same files as
> > > > > > > -the ones impacted by the merge, Git will refuse to proceed. Most of
> > > > > > > +the ones affected by the merge, Git will refuse to proceed. Most of
> > > > > > > the time, you will want to commit your changes before you can merge,
> > > > > > > and if you don't, then linkgit:git-stash[1] can take these changes
> > > > > > > away while you're doing the merge, and reapply them afterwards.
> > > > > > > diff --git a/advice.c b/advice.c
> > > > > > > index 164742305f..9cbbb824a9 100644
> > > > > > > --- a/advice.c
> > > > > > > +++ b/advice.c
> > > > > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> > > > > > > "\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/builtin/fast-import.c b/builtin/fast-import.c
> > > > > > > index 3afa81cf9a..24f362d2f4 100644
> > > > > > > --- a/builtin/fast-import.c
> > > > > > > +++ b/builtin/fast-import.c
> > > > > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> > > > > > > const char *prefix)
> > > > > > > * We don't parse most options until after we've seen the set of
> > > > > > > * "feature" lines at the start of the stream (which allows the command
> > > > > > > * line to override stream data). But we must do an early parse of any
> > > > > > > - * command-line options that impact how we interpret the feature lines.
> > > > > > > + * command-line options that affect how we interpret the feature lines.
> > > > > > > */
> > > > > > > for (i = 1; i < argc; i++) {
> > > > > > > const char *arg = argv[i];
> > > > > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> > > > > > > index 525c2d8552..749bbca241 100644
> > > > > > > --- a/builtin/pack-objects.c
> > > > > > > +++ b/builtin/pack-objects.c
> > > > > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> > > > > > > /*
> > > > > > > * Mark ourselves as active and see if the next step causes
> > > > > > > * us to cycle to another active object. It's important to do
> > > > > > > - * this _before_ we loop, because it impacts where we make the
> > > > > > > + * this _before_ we loop, because it affects where we make the
> > > > > > > * cut, and thus how our total_depth counter works.
> > > > > > > * E.g., We may see a partial loop like:
> > > > > > > *
> > > > > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> > > > > > > index f0e80bd7f0..92979ec770 100644
> > > > > > > --- a/contrib/coccinelle/README
> > > > > > > +++ b/contrib/coccinelle/README
> > > > > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:
> > > > > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.
> > > > > > >
> > > > > > > This allows to expose plans of pending large scale refactorings without
> > > > > > > - impacting the bad pattern checks.
> > > > > > > + affecting the bad pattern checks.
> > > > > > > diff --git a/dir.c b/dir.c
> > > > > > > index 3474e67e8f..235e26a90e 100644
> > > > > > > --- a/dir.c
> > > > > > > +++ b/dir.c
> > > > > > > @@ -2144,7 +2144,7 @@ static enum path_treatment
> > > > > > > treat_path_fast(struct dir_struct *dir,
> > > > > > > /*
> > > > > > > * We get path_recurse in the first run when
> > > > > > > * directory_exists_in_index() returns index_nonexistent. We
> > > > > > > - * are sure that new changes in the index does not impact the
> > > > > > > + * are sure that new changes in the index does not affect the
> > > > > > > * outcome. Return now.
> > > > > > > */
> > > > > > > return path_recurse;
> > > > > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> > > > > > > index d0e0e019ea..1fcb98443c 100755
> > > > > > > --- a/t/perf/p5550-fetch-tags.sh
> > > > > > > +++ b/t/perf/p5550-fetch-tags.sh
> > > > > > > @@ -8,7 +8,7 @@ follows.
> > > > > > >
> > > > > > > The parent repository has a large number of tags which are disconnected from
> > > > > > > the rest of history. That makes them candidates for tag-following, but we never
> > > > > > > -actually grab them (and thus they will impact each subsequent fetch).
> > > > > > > +actually grab them (and thus they will affect each subsequent fetch).
> > > > > > >
> > > > > > > The child repository is a clone of parent, without the tags, and is at least
> > > > > > > one commit behind the parent (meaning that we will fetch one object and then
> > > > > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> > > > > > > index a594b4aa7d..95daba4000 100755
> > > > > > > --- a/t/t0008-ignores.sh
> > > > > > > +++ b/t/t0008-ignores.sh
> > > > > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> > > > > > > # test standard ignores
> > > > > > >
> > > > > > > # First make sure that the presence of a file in the working tree
> > > > > > > -# does not impact results, but that the presence of a file in the
> > > > > > > +# does not affect results, but that the presence of a file in the
> > > > > > > # index does unless the --no-index option is used.
> > > > > > >
> > > > > > > for subdir in '' 'a/'
> > > > > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> > > > > > > index f028fd1418..a9348f655a 100755
> > > > > > > --- a/t/t0303-credential-external.sh
> > > > > > > +++ b/t/t0303-credential-external.sh
> > > > > > > @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> > > > > > > eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
> > > > > > >
> > > > > > > # clean before the test in case there is cruft left
> > > > > > > -# over from a previous run that would impact results
> > > > > > > +# over from a previous run that would affect results
> > > > > > > helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
> > > > > > >
> > > > > > > helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> > > > > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> > > > > > > index bc46713a43..568c258c5a 100755
> > > > > > > --- a/t/t2020-checkout-detach.sh
> > > > > > > +++ b/t/t2020-checkout-detach.sh
> > > > > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> > > > > > > no SHA-1 ellipsis when not as
> > > > > > >
> > > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > > - state without impacting any branches by switching back to a branch.
> > > > > > > + state without affecting any branches by switching back to a branch.
> > > > > > >
> > > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > > do so (now or later) by using -c with the switch command. Example:
> > > > > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> > > > > > > print SHA-1 ellipsis when asked
> > > > > > >
> > > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > > - state without impacting any branches by switching back to a branch.
> > > > > > > + state without affecting any branches by switching back to a branch.
> > > > > > >
> > > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > > do so (now or later) by using -c with the switch command. Example:
> > > > > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> > > > > > > index 6cca8b84a6..97365a7786 100755
> > > > > > > --- a/t/t4013-diff-various.sh
> > > > > > > +++ b/t/t4013-diff-various.sh
> > > > > > > @@ -109,7 +109,7 @@ test_expect_success setup '
> > > > > > > git checkout -f master &&
> > > > > > >
> > > > > > > # Same merge as master, but with parents reversed. Hide it in a
> > > > > > > - # pseudo-ref to avoid impacting tests with --all.
> > > > > > > + # pseudo-ref to avoid affecting tests with --all.
> > > > > > > commit=$(echo reverse |
> > > > > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&
> > > > > > > git update-ref REVERSE $commit &&
> > > > > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> > > > > > > index 7204799a0b..33a6efce2f 100755
> > > > > > > --- a/t/t5000-tar-tree.sh
> > > > > > > +++ b/t/t5000-tar-tree.sh
> > > > > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> > > > > > > # Pull the size and date of each entry in a tarfile using the system tar.
> > > > > > > #
> > > > > > > # We'll pull out only the year from the date; that avoids any question of
> > > > > > > -# timezones impacting the result (as long as we keep our test times away from a
> > > > > > > +# timezones affecting the result (as long as we keep our test times away from a
> > > > > > > # year boundary; our reference times are all in August).
> > > > > > > #
> > > > > > > # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> > > > > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> > > > > > > index 6348e8d733..ff65f86f50 100644
> > > > > > > --- a/t/test-lib-functions.sh
> > > > > > > +++ b/t/test-lib-functions.sh
> > > > > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> > > > > > > }
> > > > > > >
> > > > > > > # Like "env FOO=BAR some-program", but run inside a subshell, which means
> > > > > > > -# it also works for shell functions (though those functions cannot impact
> > > > > > > +# it also works for shell functions (though those functions cannot affect
> > > > > > > # the environment outside of the test_env invocation).
> > > > > > > test_env () {
> > > > > > > (
> > > > > > > --
> > > > > > > 2.17.1
> > > > > > >
> > > > > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada <varuncvarada@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King <peff@peff.net> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
> > > > > > > > >
> > > > > > > > > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > > > > > > > > problem the word "impact" in itself is not "jargon".
> > > > > > > > > >
> > > > > > > > > > The word means "to have a strong or marked effect on" (v.) and "a
> > > > > > > > > > strong or market influence" (n.) when used figuratively; it is not
> > > > > > > > > > synonymous with "affect" and "effect", respectively, as shown even by
> > > > > > > > > > all of the entries you've cited. Using it as such is the incorrect
> > > > > > > > > > part, so those are the instances I've changed in the diff.
> > > > > > > > >
> > > > > > > > > Er, is that true? From Michal's definitions:
> > > > > > > > >
> > > > > > > > > > > From The Collaborative International Dictionary of English v.0.48 :
> > > > > > > > > > [...]
> > > > > > > > > > > 2. To affect or influence, especially in a significant or
> > > > > > > > >
> > > > > > > > > It literally uses "affect" to define it. The "especially significant"
> > > > > > > > > does not apply to many, but I don't think that makes it necessarily
> > > > > > > > > wrong to use impact to mean "affect".
> > > > > > > >
> > > > > > > > I was drawing attention to the "especially significant" bit and the
> > > > > > > > like being there in all the entries. I'm not sure about these
> > > > > > > > dictionaries, but the definition is hyperbolic / violent / shocking in
> > > > > > > > every reputable dictionary out there: the Oxford English Dictionary,
> > > > > > > > Merriam-Webster, and Collins.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Likewise:
> > > > > > > > >
> > > > > > > > > > > From WordNet (r) 3.0 (2006) :
> > > > > > > > > > [...]
> > > > > > > > > > > v 1: press or wedge together; pack together
> > > > > > > > > > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > > > > > > > > > affect, impact, bear upon, bear on, touch on,
> > > > > > > > > > > touch]
> > > > > > > > >
> > > > > > > > > That is likewise listing "impact" and "affect" as synonyms.
> > > > > > > > >
> > > > > > > > > I do agree the word is over-used in some forms of writing, but I don't
> > > > > > > > > find anything at all confusing or wrong about the uses that you changed
> > > > > > > > > in your patch. I am a native speaker of English. I'm open to the
> > > > > > > > > argument that non-native speakers may be more confused by the word. But
> > > > > > > > > this seems like mostly a style preference thing, and I'd generally
> > > > > > > > > prefer to leave the contributions and style of the original writers
> > > > > > > > > intact unless there is a good reason not to.
> > > > > > > >
> > > > > > > > I am a native English speaker as well, and there were multiple places
> > > > > > > > where I had to think twice about what the sentences mean. I agree with
> > > > > > > > your sentiment about leaving stylistic preferences intact, but this is
> > > > > > > > actually a semantic one. And given that there is a perfectly good
> > > > > > > > alternative that doesn't have this confusion / jargon status, I wanted
> > > > > > > > to make the change to improve it, especially where it says that in the
> > > > > > > > output of the git command (`git checkout` when in detached HEAD mode).
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Such changes are doubly unwanted in cases like this:
> > > > > > > > >
> > > > > > > > > > --- a/compat/nedmalloc/malloc.c.h
> > > > > > > > > > +++ b/compat/nedmalloc/malloc.c.h
> > > > > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > > > > > > > > > #endif /* (FOOTERS && !INSECURE) */
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > > > > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > > > > > > > > > #if !INSECURE
> > > > > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3
> > > > > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)
> > > > > > > > >
> > > > > > > > > where the text is imported from another project, and we'd prefer to stay
> > > > > > > > > as close to their version as possible (e.g., to avoid unnecessary
> > > > > > > > > conflicts when pulling in new versions).
> > > > > > > >
> > > > > > > > That's fair; I wasn't aware that this was being pulled directly from
> > > > > > > > another project. I can change this back.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Also, this one should be "effect" anyway, as it is a noun.
> > > > > > > >
> > > > > > > > This seems to have slipped through, as I used a text search tool.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > -Peff
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-10 17:35 ` Michal Suchánek
@ 2021-05-10 18:37 ` Varun Varada
2021-05-11 10:43 ` Michal Suchánek
2021-05-12 2:48 ` Felipe Contreras
1 sibling, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-05-10 18:37 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Jeff King, git
On Mon, 10 May 2021 at 12:35, Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Mon, May 10, 2021 at 12:19:05PM -0500, Varun Varada wrote:
> > On Fri, 30 Apr 2021 at 02:59, Michal Suchánek <msuchanek@suse.de> wrote:
> > >
> > > On Thu, Apr 29, 2021 at 08:51:07PM -0500, Varun Varada wrote:
> > > > On Wed, 28 Apr 2021 at 13:49, Michal Suchánek <msuchanek@suse.de> wrote:
> > > > >
> > > > > On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:
> > > > > > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek <msuchanek@suse.de> wrote:
> > > > > > >
> > > > > > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:
> > > > > > > > Here's the updated diff:
> > > > > > >
> > > > > > > As already said multiple general purpose dictionaries recognize '(have)
> > > > > > > strong effect' as the meaning of 'impact', in some cases even the most
> > > > > > > common meaning.
> > > > > >
> > > > > > There's no contention here. That's the meaning I've been referring to as well.
> > > > > >
> > > > > > >
> > > > > > > In case you have some issue with the word 'jargon' Merriam-Webster gives
> > > > > > > this definition:
> > > > > > >
> > > > > > > 1: the technical terminology or characteristic idiom of a special activity or group
> > > > > > > 2: obscure and often pretentious language marked by circumlocutions and long words
> > > > > > > 3a: confused unintelligible language
> > > > > > > b: a strange, outlandish, or barbarous language or dialect
> > > > > > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech
> > > > > > >
> > > > > > > which the word 'impact' does not fulfill.
> > > > > > >
> > > > > > > Further, you would rarely discuss and document an effect that is
> > > > > > > negligible so in vast majority of cases '(have) strong effect' (ie
> > > > > > > 'impact') is synonymous to 'affect' and 'affect', respectively.
> > > > > >
> > > > > > This is not true, especially in technical contexts. "Affect" doesn't
> > > > > > mean "has a slight effect on", but simply "has an effect on". This
> > > > > > suffices in most cases. In cases where one would like to highlight the
> > > > > > overwhelming/awesome/debilitating/marked/strong effect that something
> > > > > > has, "impact" can be used. To say that every effect is overwhelming or
> > > > > > strong is jargon.
> > > > > >
> > > > > > >
> > > > > > > If you can pick out a few places where the use is specifically confusing
> > > > > > > then please pick out those. Wholesale replacement of one word with
> > > > > > > another synonym is not desired. It creates useless churn.
> > > > > >
> > > > > > I've actually not done a wholesale replacement blindly; the ones I
> > > > > > replaced are the places where I couldn't find any case where it is
> > > > > > referring to a "strong/marked effect". This is especially true in the
> > > > > > negative constructions. If you could help me find places where you
> > > > > > think the intended meaning is indeed "a strong/marked effect", I can
> > > > > > remove those from the changes.
> > > > >
> > > > > As already pointed out before the mere fact that the author of the text
> > > > > bothered to document the effect ipmlies that the effect is strong/marked
> > > > > unless stated otherwise. At any rate 'strong' is always relative. Unless
> > > > > you have a specific reference of average strenth anything can be
> > > > > considered strong or weak depending on point of view.
> > > >
> > > > This doesn't seem like a plausible or strong argument given the
> > > > context of the places where I'm editing the text. Most of them are
> > > > negative constructions, where if one were to assume "strongly affect"
> > >
> > > That's not the case. There are some which include negation, and many
> > > that don't. I did not review all of the patch so can't really tell but
> > > it looks like the onse that include negation are a minority or about
> > > half of what you replace at best.
> >
> > There are 27 changes, 16 of which are negation. That's more than half,
> > and at least all of these need to be replaced.
> >
> > >
> > > > was intended, then that raises the question of what actual effect it
> > > > will have. The only convincing example of this I can see is the one
> > > > where it reads "which are tight with memory might be badly impacted by
> > > > this though". All of the other ones seem like they're binary in
> > > > whether they will have an effect at all or no, not graduated in terms
> > > > of the degree of the effect it will have.
> > >
> > > Which also means that the distinction between 'strong effect' and
> > > 'effect' is meaningless, and 'affect' vs 'impact' is synonymous.
> > > Replacing one with the other is useless churn then.
> >
> > I'm not sure I understand what you mean by "churn". No one would stop
> > using Git because of these single-word changes.
>
> It refers to redundant changes to the codebase which do not improve it in
> any way.
I see. These changes remove the confusion about what the words mean,
so they are not changes for the sake of changes.
>
> >
> > As for there being no distinction, there's no gradation within the
> > semantics of this context; this doesn't change the semantics of the
> > words themselves. Using "impact" when what is meant is just "effect"
> > or "affect" is incorrect in all such instances.
>
> That's your opinion not shared by the authors of the text.
Are you referring to part about it changing the semantics of the
words, or that it is incorrect to use them as such? Because neither of
those are opinion; I've already cited sources that attest to this, and
you've also agreed about the meaning of the words in question.
Also, I'm getting the sense that you are one of the authors of the
text being changed; am I correct in presuming this?
>
> The authority you refer to is MIT which is known for technical
> brilliance but not as authority on linguistics.
I also cited the Oxford English Dictionary and the Modern Language
Association (MLA), arguably *the* authorities on the English language
that are prevalent and popular for their guidance on usage.
>
> >
> > >
> > > Also the cases I saw do not really look confusing in any way so the
> > > change does not improve the documentation in any way.
> >
> > Saying "will not impact" means "will not strongly affect", as you've
> > already agreed. This necessarily means it might affect it, albeit not
> > strongly.
>
> Or not at all.
Sure. So, which is it? And how will the reader know which it is? This
is my point. There's absolutely no reason to have this confusion.
>
> > This is confusing to anyone reading the documentation, and
>
> When the distinction is not meaningful it is not really confusing in
> this use, either.
>
> > is entirely unnecessary.
>
> Also you did not limit your patch to these cases that you say are
> confusing.
>
> > I don't understand the resistance here for
> > simple one-word changes that remove this confusion. Am I missing
> > something?
>
> There does not seem to be any confusion to remove, at least you have not
> pointed out any specific case that is particularly confusing.
I've pointed out that all of the negation examples are confusing
because they are ambiguous.
>
> If you do wholesale word replacement in the project for no good reason
> it only makes working with the project history harder.
I'm not sure I understand the sentiment here. As in, the Git history
will be polluted? Because the "git blame" command will only show
changes for the lines where I changed the single words.
And it reduces ambiguity in the command output, let alone the
documentation; it is not pointless. If it wasn't confusing enough for
a native English-speaking everyday user of Git, I wouldn't have taken
the time to read through all of the documentation about how to submit
patches to Git, followed all of the procedures, learned to work with
some new Git commands, and actually made the changes to get all the
way here just to make changes to the repository for the sake of it; I
promise.
>
> Thanks
>
> Michal
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > You could make a case that 'impact' is significantly less frequent word
> > > > > > > compared to effect/affect and thus makes the text harder to understand
> > > > > > > for non-native speakers. However, that's not the point you brought up,
> > > > > > > and even then it is very weak point to make, especially without any
> > > > > > > actual source for the frequency data. You could also counter that all of
> > > > > > > these are common loanwords in many languages and are thus easy to
> > > > > > > understand to non-native speakers anyway.
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Michal
> > > > > > > >
> > > > > > > > Documentation/MyFirstContribution.txt | 2 +-
> > > > > > > > Documentation/MyFirstObjectWalk.txt | 2 +-
> > > > > > > > Documentation/config/pack.txt | 2 +-
> > > > > > > > Documentation/git-fast-import.txt | 14 +++++++-------
> > > > > > > > Documentation/git-fetch.txt | 2 +-
> > > > > > > > .../technical/hash-function-transition.txt | 2 +-
> > > > > > > > Documentation/user-manual.txt | 4 ++--
> > > > > > > > advice.c | 2 +-
> > > > > > > > builtin/fast-import.c | 2 +-
> > > > > > > > builtin/pack-objects.c | 2 +-
> > > > > > > > contrib/coccinelle/README | 2 +-
> > > > > > > > dir.c | 2 +-
> > > > > > > > t/perf/p5550-fetch-tags.sh | 2 +-
> > > > > > > > t/t0008-ignores.sh | 2 +-
> > > > > > > > t/t0303-credential-external.sh | 2 +-
> > > > > > > > t/t2020-checkout-detach.sh | 4 ++--
> > > > > > > > t/t4013-diff-various.sh | 2 +-
> > > > > > > > t/t5000-tar-tree.sh | 2 +-
> > > > > > > > t/test-lib-functions.sh | 2 +-
> > > > > > > > 19 files changed, 27 insertions(+), 27 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/Documentation/MyFirstContribution.txt
> > > > > > > > b/Documentation/MyFirstContribution.txt
> > > > > > > > index af0a9da62e..8372a7e59e 100644
> > > > > > > > --- a/Documentation/MyFirstContribution.txt
> > > > > > > > +++ b/Documentation/MyFirstContribution.txt
> > > > > > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> > > > > > > > how to show it in the general
> > > > > > > > command list shown by `git help git` or `git help -a`, which is generated from
> > > > > > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> > > > > > > > line above it in alphabetical order. Now, we can add some attributes about the
> > > > > > > > -command which impacts where it shows up in the aforementioned help
> > > > > > > > commands. The
> > > > > > > > +command which affects where it shows up in the aforementioned help
> > > > > > > > commands. The
> > > > > > > > top of `command-list.txt` shares some information about what each attribute
> > > > > > > > means; in those help pages, the commands are sorted according to these
> > > > > > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> > > > > > > > diff --git a/Documentation/MyFirstObjectWalk.txt
> > > > > > > > b/Documentation/MyFirstObjectWalk.txt
> > > > > > > > index 2d10eea7a9..fd5bb8fb7d 100644
> > > > > > > > --- a/Documentation/MyFirstObjectWalk.txt
> > > > > > > > +++ b/Documentation/MyFirstObjectWalk.txt
> > > > > > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> > > > > > > > By running your walk with and without the filter, you should find
> > > > > > > > that the total
> > > > > > > > object count in each case is identical. You can also time each invocation of
> > > > > > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm
> > > > > > > > -to yourself the runtime impact of tracking all omitted objects.
> > > > > > > > +to yourself the runtime effect of tracking all omitted objects.
> > > > > > > >
> > > > > > > > === Changing the Order
> > > > > > > >
> > > > > > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> > > > > > > > index 3da4ea98e2..00fcc9d7c7 100644
> > > > > > > > --- a/Documentation/config/pack.txt
> > > > > > > > +++ b/Documentation/config/pack.txt
> > > > > > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> > > > > > > > This cache is used to speed up the writing object phase by not
> > > > > > > > having to recompute the final delta result once the best match
> > > > > > > > for all objects is found. Repacking large repositories on machines
> > > > > > > > - which are tight with memory might be badly impacted by this though,
> > > > > > > > + which are tight with memory might be badly affected by this though,
> > > > > > > > especially if this cache pushes the system into swapping.
> > > > > > > > A value of 0 means no limit. The smallest size of 1 byte may be
> > > > > > > > used to virtually disable this cache. Defaults to 256 MiB.
> > > > > > > > diff --git a/Documentation/git-fast-import.txt
> > > > > > > > b/Documentation/git-fast-import.txt
> > > > > > > > index 39cfa05b28..c6d8e4e1d7 100644
> > > > > > > > --- a/Documentation/git-fast-import.txt
> > > > > > > > +++ b/Documentation/git-fast-import.txt
> > > > > > > > @@ -58,7 +58,7 @@ OPTIONS
> > > > > > > > allowing fast-import to access the filesystem outside of the
> > > > > > > > repository). These options are disabled by default, but can be
> > > > > > > > allowed by providing this option on the command line. This
> > > > > > > > - currently impacts only the `export-marks`, `import-marks`, and
> > > > > > > > + currently affects only the `export-marks`, `import-marks`, and
> > > > > > > > `import-marks-if-exists` feature commands.
> > > > > > > > +
> > > > > > > > Only enable this option if you trust the program generating the
> > > > > > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
> > > > > > > >
> > > > > > > > A `filecopy` command takes effect immediately. Once the source
> > > > > > > > location has been copied to the destination any future commands
> > > > > > > > -applied to the source location will not impact the destination of
> > > > > > > > +applied to the source location will not affect the destination of
> > > > > > > > the copy.
> > > > > > > >
> > > > > > > > `filerename`
> > > > > > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> > > > > > > > A `filerename` command takes effect immediately. Once the source
> > > > > > > > location has been renamed to the destination any future commands
> > > > > > > > applied to the source location will create new files there and not
> > > > > > > > -impact the destination of the rename.
> > > > > > > > +affect the destination of the rename.
> > > > > > > >
> > > > > > > > Note that a `filerename` is the same as a `filecopy` followed by a
> > > > > > > > `filedelete` of the source location. There is a slight performance
> > > > > > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> > > > > > > > to be required).
> > > > > > > > ~~~~~~~~~~
> > > > > > > > Causes fast-import to print the entire `progress` line unmodified to
> > > > > > > > its standard output channel (file descriptor 1) when the command is
> > > > > > > > -processed from the input stream. The command otherwise has no impact
> > > > > > > > +processed from the input stream. The command otherwise has no effect
> > > > > > > > on the current import, or on any of fast-import's internal state.
> > > > > > > >
> > > > > > > > ....
> > > > > > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> > > > > > > > ~~~~~~~~~~
> > > > > > > > Causes fast-import to print the SHA-1 corresponding to a mark to
> > > > > > > > stdout or to the file descriptor previously arranged with the
> > > > > > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the
> > > > > > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the
> > > > > > > > current import; its purpose is to retrieve SHA-1s that later commits
> > > > > > > > might want to refer to in their commit messages.
> > > > > > > >
> > > > > > > > @@ -1050,7 +1050,7 @@ this output safely.
> > > > > > > > ~~~~~~~~~~
> > > > > > > > Causes fast-import to print a blob to a file descriptor previously
> > > > > > > > arranged with the `--cat-blob-fd` argument. The command otherwise
> > > > > > > > -has no impact on the current import; its main purpose is to
> > > > > > > > +has no effect on the current import; its main purpose is to
> > > > > > > > retrieve blobs that may be in fast-import's memory but not
> > > > > > > > accessible from the target repository.
> > > > > > > >
> > > > > > > > @@ -1366,7 +1366,7 @@ code considerably.
> > > > > > > >
> > > > > > > > The branch LRU builtin to fast-import tends to behave very well, and the
> > > > > > > > cost of activating an inactive branch is so low that bouncing around
> > > > > > > > -between branches has virtually no impact on import performance.
> > > > > > > > +between branches has virtually no effect on import performance.
> > > > > > > >
> > > > > > > > Handling Renames
> > > > > > > > ~~~~~~~~~~~~~~~~
> > > > > > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> > > > > > > > index 9067c2079e..01cf3b3d16 100644
> > > > > > > > --- a/Documentation/git-fetch.txt
> > > > > > > > +++ b/Documentation/git-fetch.txt
> > > > > > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> > > > > > > > If left to accumulate, these stale references might make performance
> > > > > > > > worse on big and busy repos that have a lot of branch churn, and
> > > > > > > > e.g. make the output of commands like `git branch -a --contains
> > > > > > > > -<commit>` needlessly verbose, as well as impacting anything else
> > > > > > > > +<commit>` needlessly verbose, as well as affecting anything else
> > > > > > > > that'll work with the complete set of known references.
> > > > > > > >
> > > > > > > > These remote-tracking references can be deleted as a one-off with
> > > > > > > > diff --git a/Documentation/technical/hash-function-transition.txt
> > > > > > > > b/Documentation/technical/hash-function-transition.txt
> > > > > > > > index 7c1630bf83..f4296faffc 100644
> > > > > > > > --- a/Documentation/technical/hash-function-transition.txt
> > > > > > > > +++ b/Documentation/technical/hash-function-transition.txt
> > > > > > > > @@ -42,7 +42,7 @@ mitigations.
> > > > > > > >
> > > > > > > > If SHA-1 and its variants were to be truly broken, Git's hash function
> > > > > > > > could not be considered cryptographically secure any more. This would
> > > > > > > > -impact the communication of hash values because we could not trust
> > > > > > > > +affect the communication of hash values because we could not trust
> > > > > > > > that a given hash value represented the known good version of content
> > > > > > > > that the speaker intended.
> > > > > > > >
> > > > > > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > > > > > > > index fd480b8645..33c60c49d7 100644
> > > > > > > > --- a/Documentation/user-manual.txt
> > > > > > > > +++ b/Documentation/user-manual.txt
> > > > > > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
> > > > > > > >
> > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > > > -state without impacting any branches by performing another switch.
> > > > > > > > +state without affecting any branches by performing another switch.
> > > > > > > >
> > > > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > > > do so (now or later) by using -c with the switch command again. Example:
> > > > > > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> > > > > > > > overwritten by the result of
> > > > > > > > the merge when this combining is done cleanly, or overwritten by a
> > > > > > > > half-merged results when this combining results in conflicts.
> > > > > > > > Therefore, if you have uncommitted changes touching the same files as
> > > > > > > > -the ones impacted by the merge, Git will refuse to proceed. Most of
> > > > > > > > +the ones affected by the merge, Git will refuse to proceed. Most of
> > > > > > > > the time, you will want to commit your changes before you can merge,
> > > > > > > > and if you don't, then linkgit:git-stash[1] can take these changes
> > > > > > > > away while you're doing the merge, and reapply them afterwards.
> > > > > > > > diff --git a/advice.c b/advice.c
> > > > > > > > index 164742305f..9cbbb824a9 100644
> > > > > > > > --- a/advice.c
> > > > > > > > +++ b/advice.c
> > > > > > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> > > > > > > > "\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/builtin/fast-import.c b/builtin/fast-import.c
> > > > > > > > index 3afa81cf9a..24f362d2f4 100644
> > > > > > > > --- a/builtin/fast-import.c
> > > > > > > > +++ b/builtin/fast-import.c
> > > > > > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> > > > > > > > const char *prefix)
> > > > > > > > * We don't parse most options until after we've seen the set of
> > > > > > > > * "feature" lines at the start of the stream (which allows the command
> > > > > > > > * line to override stream data). But we must do an early parse of any
> > > > > > > > - * command-line options that impact how we interpret the feature lines.
> > > > > > > > + * command-line options that affect how we interpret the feature lines.
> > > > > > > > */
> > > > > > > > for (i = 1; i < argc; i++) {
> > > > > > > > const char *arg = argv[i];
> > > > > > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> > > > > > > > index 525c2d8552..749bbca241 100644
> > > > > > > > --- a/builtin/pack-objects.c
> > > > > > > > +++ b/builtin/pack-objects.c
> > > > > > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> > > > > > > > /*
> > > > > > > > * Mark ourselves as active and see if the next step causes
> > > > > > > > * us to cycle to another active object. It's important to do
> > > > > > > > - * this _before_ we loop, because it impacts where we make the
> > > > > > > > + * this _before_ we loop, because it affects where we make the
> > > > > > > > * cut, and thus how our total_depth counter works.
> > > > > > > > * E.g., We may see a partial loop like:
> > > > > > > > *
> > > > > > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> > > > > > > > index f0e80bd7f0..92979ec770 100644
> > > > > > > > --- a/contrib/coccinelle/README
> > > > > > > > +++ b/contrib/coccinelle/README
> > > > > > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:
> > > > > > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.
> > > > > > > >
> > > > > > > > This allows to expose plans of pending large scale refactorings without
> > > > > > > > - impacting the bad pattern checks.
> > > > > > > > + affecting the bad pattern checks.
> > > > > > > > diff --git a/dir.c b/dir.c
> > > > > > > > index 3474e67e8f..235e26a90e 100644
> > > > > > > > --- a/dir.c
> > > > > > > > +++ b/dir.c
> > > > > > > > @@ -2144,7 +2144,7 @@ static enum path_treatment
> > > > > > > > treat_path_fast(struct dir_struct *dir,
> > > > > > > > /*
> > > > > > > > * We get path_recurse in the first run when
> > > > > > > > * directory_exists_in_index() returns index_nonexistent. We
> > > > > > > > - * are sure that new changes in the index does not impact the
> > > > > > > > + * are sure that new changes in the index does not affect the
> > > > > > > > * outcome. Return now.
> > > > > > > > */
> > > > > > > > return path_recurse;
> > > > > > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> > > > > > > > index d0e0e019ea..1fcb98443c 100755
> > > > > > > > --- a/t/perf/p5550-fetch-tags.sh
> > > > > > > > +++ b/t/perf/p5550-fetch-tags.sh
> > > > > > > > @@ -8,7 +8,7 @@ follows.
> > > > > > > >
> > > > > > > > The parent repository has a large number of tags which are disconnected from
> > > > > > > > the rest of history. That makes them candidates for tag-following, but we never
> > > > > > > > -actually grab them (and thus they will impact each subsequent fetch).
> > > > > > > > +actually grab them (and thus they will affect each subsequent fetch).
> > > > > > > >
> > > > > > > > The child repository is a clone of parent, without the tags, and is at least
> > > > > > > > one commit behind the parent (meaning that we will fetch one object and then
> > > > > > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> > > > > > > > index a594b4aa7d..95daba4000 100755
> > > > > > > > --- a/t/t0008-ignores.sh
> > > > > > > > +++ b/t/t0008-ignores.sh
> > > > > > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> > > > > > > > # test standard ignores
> > > > > > > >
> > > > > > > > # First make sure that the presence of a file in the working tree
> > > > > > > > -# does not impact results, but that the presence of a file in the
> > > > > > > > +# does not affect results, but that the presence of a file in the
> > > > > > > > # index does unless the --no-index option is used.
> > > > > > > >
> > > > > > > > for subdir in '' 'a/'
> > > > > > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> > > > > > > > index f028fd1418..a9348f655a 100755
> > > > > > > > --- a/t/t0303-credential-external.sh
> > > > > > > > +++ b/t/t0303-credential-external.sh
> > > > > > > > @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> > > > > > > > eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
> > > > > > > >
> > > > > > > > # clean before the test in case there is cruft left
> > > > > > > > -# over from a previous run that would impact results
> > > > > > > > +# over from a previous run that would affect results
> > > > > > > > helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
> > > > > > > >
> > > > > > > > helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> > > > > > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> > > > > > > > index bc46713a43..568c258c5a 100755
> > > > > > > > --- a/t/t2020-checkout-detach.sh
> > > > > > > > +++ b/t/t2020-checkout-detach.sh
> > > > > > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> > > > > > > > no SHA-1 ellipsis when not as
> > > > > > > >
> > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > > > - state without impacting any branches by switching back to a branch.
> > > > > > > > + state without affecting any branches by switching back to a branch.
> > > > > > > >
> > > > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > > > do so (now or later) by using -c with the switch command. Example:
> > > > > > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> > > > > > > > print SHA-1 ellipsis when asked
> > > > > > > >
> > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > > > - state without impacting any branches by switching back to a branch.
> > > > > > > > + state without affecting any branches by switching back to a branch.
> > > > > > > >
> > > > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > > > do so (now or later) by using -c with the switch command. Example:
> > > > > > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> > > > > > > > index 6cca8b84a6..97365a7786 100755
> > > > > > > > --- a/t/t4013-diff-various.sh
> > > > > > > > +++ b/t/t4013-diff-various.sh
> > > > > > > > @@ -109,7 +109,7 @@ test_expect_success setup '
> > > > > > > > git checkout -f master &&
> > > > > > > >
> > > > > > > > # Same merge as master, but with parents reversed. Hide it in a
> > > > > > > > - # pseudo-ref to avoid impacting tests with --all.
> > > > > > > > + # pseudo-ref to avoid affecting tests with --all.
> > > > > > > > commit=$(echo reverse |
> > > > > > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&
> > > > > > > > git update-ref REVERSE $commit &&
> > > > > > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> > > > > > > > index 7204799a0b..33a6efce2f 100755
> > > > > > > > --- a/t/t5000-tar-tree.sh
> > > > > > > > +++ b/t/t5000-tar-tree.sh
> > > > > > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> > > > > > > > # Pull the size and date of each entry in a tarfile using the system tar.
> > > > > > > > #
> > > > > > > > # We'll pull out only the year from the date; that avoids any question of
> > > > > > > > -# timezones impacting the result (as long as we keep our test times away from a
> > > > > > > > +# timezones affecting the result (as long as we keep our test times away from a
> > > > > > > > # year boundary; our reference times are all in August).
> > > > > > > > #
> > > > > > > > # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> > > > > > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> > > > > > > > index 6348e8d733..ff65f86f50 100644
> > > > > > > > --- a/t/test-lib-functions.sh
> > > > > > > > +++ b/t/test-lib-functions.sh
> > > > > > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> > > > > > > > }
> > > > > > > >
> > > > > > > > # Like "env FOO=BAR some-program", but run inside a subshell, which means
> > > > > > > > -# it also works for shell functions (though those functions cannot impact
> > > > > > > > +# it also works for shell functions (though those functions cannot affect
> > > > > > > > # the environment outside of the test_env invocation).
> > > > > > > > test_env () {
> > > > > > > > (
> > > > > > > > --
> > > > > > > > 2.17.1
> > > > > > > >
> > > > > > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada <varuncvarada@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King <peff@peff.net> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
> > > > > > > > > >
> > > > > > > > > > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > > > > > > > > > problem the word "impact" in itself is not "jargon".
> > > > > > > > > > >
> > > > > > > > > > > The word means "to have a strong or marked effect on" (v.) and "a
> > > > > > > > > > > strong or market influence" (n.) when used figuratively; it is not
> > > > > > > > > > > synonymous with "affect" and "effect", respectively, as shown even by
> > > > > > > > > > > all of the entries you've cited. Using it as such is the incorrect
> > > > > > > > > > > part, so those are the instances I've changed in the diff.
> > > > > > > > > >
> > > > > > > > > > Er, is that true? From Michal's definitions:
> > > > > > > > > >
> > > > > > > > > > > > From The Collaborative International Dictionary of English v.0.48 :
> > > > > > > > > > > [...]
> > > > > > > > > > > > 2. To affect or influence, especially in a significant or
> > > > > > > > > >
> > > > > > > > > > It literally uses "affect" to define it. The "especially significant"
> > > > > > > > > > does not apply to many, but I don't think that makes it necessarily
> > > > > > > > > > wrong to use impact to mean "affect".
> > > > > > > > >
> > > > > > > > > I was drawing attention to the "especially significant" bit and the
> > > > > > > > > like being there in all the entries. I'm not sure about these
> > > > > > > > > dictionaries, but the definition is hyperbolic / violent / shocking in
> > > > > > > > > every reputable dictionary out there: the Oxford English Dictionary,
> > > > > > > > > Merriam-Webster, and Collins.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Likewise:
> > > > > > > > > >
> > > > > > > > > > > > From WordNet (r) 3.0 (2006) :
> > > > > > > > > > > [...]
> > > > > > > > > > > > v 1: press or wedge together; pack together
> > > > > > > > > > > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > > > > > > > > > > affect, impact, bear upon, bear on, touch on,
> > > > > > > > > > > > touch]
> > > > > > > > > >
> > > > > > > > > > That is likewise listing "impact" and "affect" as synonyms.
> > > > > > > > > >
> > > > > > > > > > I do agree the word is over-used in some forms of writing, but I don't
> > > > > > > > > > find anything at all confusing or wrong about the uses that you changed
> > > > > > > > > > in your patch. I am a native speaker of English. I'm open to the
> > > > > > > > > > argument that non-native speakers may be more confused by the word. But
> > > > > > > > > > this seems like mostly a style preference thing, and I'd generally
> > > > > > > > > > prefer to leave the contributions and style of the original writers
> > > > > > > > > > intact unless there is a good reason not to.
> > > > > > > > >
> > > > > > > > > I am a native English speaker as well, and there were multiple places
> > > > > > > > > where I had to think twice about what the sentences mean. I agree with
> > > > > > > > > your sentiment about leaving stylistic preferences intact, but this is
> > > > > > > > > actually a semantic one. And given that there is a perfectly good
> > > > > > > > > alternative that doesn't have this confusion / jargon status, I wanted
> > > > > > > > > to make the change to improve it, especially where it says that in the
> > > > > > > > > output of the git command (`git checkout` when in detached HEAD mode).
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Such changes are doubly unwanted in cases like this:
> > > > > > > > > >
> > > > > > > > > > > --- a/compat/nedmalloc/malloc.c.h
> > > > > > > > > > > +++ b/compat/nedmalloc/malloc.c.h
> > > > > > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > > > > > > > > > > #endif /* (FOOTERS && !INSECURE) */
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > > > > > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > > > > > > > > > > #if !INSECURE
> > > > > > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3
> > > > > > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)
> > > > > > > > > >
> > > > > > > > > > where the text is imported from another project, and we'd prefer to stay
> > > > > > > > > > as close to their version as possible (e.g., to avoid unnecessary
> > > > > > > > > > conflicts when pulling in new versions).
> > > > > > > > >
> > > > > > > > > That's fair; I wasn't aware that this was being pulled directly from
> > > > > > > > > another project. I can change this back.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Also, this one should be "effect" anyway, as it is a noun.
> > > > > > > > >
> > > > > > > > > This seems to have slipped through, as I used a text search tool.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > -Peff
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-10 18:37 ` Varun Varada
@ 2021-05-11 10:43 ` Michal Suchánek
2021-05-11 13:22 ` Junio C Hamano
2021-05-12 2:59 ` Felipe Contreras
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-05-11 10:43 UTC (permalink / raw)
To: Varun Varada; +Cc: Jeff King, git
On Mon, May 10, 2021 at 01:37:45PM -0500, Varun Varada wrote:
> On Mon, 10 May 2021 at 12:35, Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > On Mon, May 10, 2021 at 12:19:05PM -0500, Varun Varada wrote:
> > > On Fri, 30 Apr 2021 at 02:59, Michal Suchánek <msuchanek@suse.de> wrote:
> > > >
> > > > On Thu, Apr 29, 2021 at 08:51:07PM -0500, Varun Varada wrote:
> > > > > On Wed, 28 Apr 2021 at 13:49, Michal Suchánek <msuchanek@suse.de> wrote:
> > > > > >
> > > > > > On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote:
> > > > > > > On Wed, 28 Apr 2021 at 03:58, Michal Suchánek <msuchanek@suse.de> wrote:
> > > > > > > >
> > > > > > > > On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:
> > > > > > > > > Here's the updated diff:
> > > > > > > >
> > > > > > > > As already said multiple general purpose dictionaries recognize '(have)
> > > > > > > > strong effect' as the meaning of 'impact', in some cases even the most
> > > > > > > > common meaning.
> > > > > > >
> > > > > > > There's no contention here. That's the meaning I've been referring to as well.
> > > > > > >
> > > > > > > >
> > > > > > > > In case you have some issue with the word 'jargon' Merriam-Webster gives
> > > > > > > > this definition:
> > > > > > > >
> > > > > > > > 1: the technical terminology or characteristic idiom of a special activity or group
> > > > > > > > 2: obscure and often pretentious language marked by circumlocutions and long words
> > > > > > > > 3a: confused unintelligible language
> > > > > > > > b: a strange, outlandish, or barbarous language or dialect
> > > > > > > > c: a hybrid language or dialect simplified in vocabulary and grammar and used for communication between peoples of different speech
> > > > > > > >
> > > > > > > > which the word 'impact' does not fulfill.
> > > > > > > >
> > > > > > > > Further, you would rarely discuss and document an effect that is
> > > > > > > > negligible so in vast majority of cases '(have) strong effect' (ie
> > > > > > > > 'impact') is synonymous to 'affect' and 'affect', respectively.
> > > > > > >
> > > > > > > This is not true, especially in technical contexts. "Affect" doesn't
> > > > > > > mean "has a slight effect on", but simply "has an effect on". This
> > > > > > > suffices in most cases. In cases where one would like to highlight the
> > > > > > > overwhelming/awesome/debilitating/marked/strong effect that something
> > > > > > > has, "impact" can be used. To say that every effect is overwhelming or
> > > > > > > strong is jargon.
> > > > > > >
> > > > > > > >
> > > > > > > > If you can pick out a few places where the use is specifically confusing
> > > > > > > > then please pick out those. Wholesale replacement of one word with
> > > > > > > > another synonym is not desired. It creates useless churn.
> > > > > > >
> > > > > > > I've actually not done a wholesale replacement blindly; the ones I
> > > > > > > replaced are the places where I couldn't find any case where it is
> > > > > > > referring to a "strong/marked effect". This is especially true in the
> > > > > > > negative constructions. If you could help me find places where you
> > > > > > > think the intended meaning is indeed "a strong/marked effect", I can
> > > > > > > remove those from the changes.
> > > > > >
> > > > > > As already pointed out before the mere fact that the author of the text
> > > > > > bothered to document the effect ipmlies that the effect is strong/marked
> > > > > > unless stated otherwise. At any rate 'strong' is always relative. Unless
> > > > > > you have a specific reference of average strenth anything can be
> > > > > > considered strong or weak depending on point of view.
> > > > >
> > > > > This doesn't seem like a plausible or strong argument given the
> > > > > context of the places where I'm editing the text. Most of them are
> > > > > negative constructions, where if one were to assume "strongly affect"
> > > >
> > > > That's not the case. There are some which include negation, and many
> > > > that don't. I did not review all of the patch so can't really tell but
> > > > it looks like the onse that include negation are a minority or about
> > > > half of what you replace at best.
> > >
> > > There are 27 changes, 16 of which are negation. That's more than half,
> > > and at least all of these need to be replaced.
> > >
> > > >
> > > > > was intended, then that raises the question of what actual effect it
> > > > > will have. The only convincing example of this I can see is the one
> > > > > where it reads "which are tight with memory might be badly impacted by
> > > > > this though". All of the other ones seem like they're binary in
> > > > > whether they will have an effect at all or no, not graduated in terms
> > > > > of the degree of the effect it will have.
> > > >
> > > > Which also means that the distinction between 'strong effect' and
> > > > 'effect' is meaningless, and 'affect' vs 'impact' is synonymous.
> > > > Replacing one with the other is useless churn then.
> > >
> > > I'm not sure I understand what you mean by "churn". No one would stop
> > > using Git because of these single-word changes.
> >
> > It refers to redundant changes to the codebase which do not improve it in
> > any way.
>
> I see. These changes remove the confusion about what the words mean,
> so they are not changes for the sake of changes.
>
> >
> > >
> > > As for there being no distinction, there's no gradation within the
> > > semantics of this context; this doesn't change the semantics of the
> > > words themselves. Using "impact" when what is meant is just "effect"
> > > or "affect" is incorrect in all such instances.
> >
> > That's your opinion not shared by the authors of the text.
>
> Are you referring to part about it changing the semantics of the
> words, or that it is incorrect to use them as such? Because neither of
> those are opinion; I've already cited sources that attest to this, and
> you've also agreed about the meaning of the words in question.
> > > already agreed. This necessarily means it might affect it, albeit not
> > > strongly.
> >
> > Or not at all.
>
> Sure. So, which is it? And how will the reader know which it is? This
> is my point. There's absolutely no reason to have this confusion.
>
> Also, I'm getting the sense that you are one of the authors of the
> text being changed; am I correct in presuming this?
No, I am not.
>
> >
> > The authority you refer to is MIT which is known for technical
> > brilliance but not as authority on linguistics.
>
> I also cited the Oxford English Dictionary and the Modern Language
> Association (MLA), arguably *the* authorities on the English language
> that are prevalent and popular for their guidance on usage.
The dictionaries define 'impact' as '(having) strong effect'. They do
not define when it is appropriate to use the word 'impact'.
With the tendency of at least some English speakers to use superlatives
needlessly the use of 'impact' as synonym for affect/effect is not
surprising.
Also there is no single authority on the English language. The language
is spoken in multiple distinct countries, and even within one country
there is some variation. It also evolves over time.
Since you can look up the meaning of the word in a general purpose
dictionary it should be an acceptable use even if it's less commonly
used in some other English-speaking parts of the world.
>
> >
> > >
> > > >
> > > > Also the cases I saw do not really look confusing in any way so the
> > > > change does not improve the documentation in any way.
> > >
> > > Saying "will not impact" means "will not strongly affect", as you've
>
> >
> > > This is confusing to anyone reading the documentation, and
> >
> > When the distinction is not meaningful it is not really confusing in
> > this use, either.
> >
> > > is entirely unnecessary.
> >
> > Also you did not limit your patch to these cases that you say are
> > confusing.
> >
> > > I don't understand the resistance here for
> > > simple one-word changes that remove this confusion. Am I missing
> > > something?
> >
> > There does not seem to be any confusion to remove, at least you have not
> > pointed out any specific case that is particularly confusing.
>
> I've pointed out that all of the negation examples are confusing
> because they are ambiguous.
They are not confusing in the way they are used. That is 'does not
impact' in the maning 'has no or negligible effect', and especially in
the cases where the degree of effect is not considered and only there
being an effect or not is discussed there is no room for confusion.
>
> >
> > If you do wholesale word replacement in the project for no good reason
> > it only makes working with the project history harder.
>
> I'm not sure I understand the sentiment here. As in, the Git history
> will be polluted? Because the "git blame" command will only show
> changes for the lines where I changed the single words.
Yes, it will be polluted. And since we have an opinion of another native
English speaker that the use of 'impact' as synonym for affect/effect is
fine this is clearly a matter of opinion.
Also we have the opinion of the author of the text that such use is fine
which is the most relevant unless solid evidence is provided that such
use is indeed wrong and/or generally impedes understanding of the text.
Clearly even a native speakers of a language can be sometimes confused
by one word or another, and unless it is shown to be a general problem
we would get into a back and forth replacing words with another synonym
that somebody happens to find less confusing.
An interesting case of this is when correctors that come from different
places change a line back and forth because in the place where they come
from one word (order) is more common and sounds more natural than the
other.
This topic somewhat interests me so I was continuing this discussion
in the hope that you either provide a specific very confusing use of the
word impact in the documentation that triggered creating this patch or
some solid evidence that the general use of word 'impact' as synonym for
affect/effect is in some way problematic but niether happened.
I think this topic has been discussed sufficiently and there is nothing
more to add.
Thanks
Michal
>
> And it reduces ambiguity in the command output, let alone the
> documentation; it is not pointless. If it wasn't confusing enough for
> a native English-speaking everyday user of Git, I wouldn't have taken
> the time to read through all of the documentation about how to submit
> patches to Git, followed all of the procedures, learned to work with
> some new Git commands, and actually made the changes to get all the
> way here just to make changes to the repository for the sake of it; I
> promise.
>
> >
> > Thanks
> >
> > Michal
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > You could make a case that 'impact' is significantly less frequent word
> > > > > > > > compared to effect/affect and thus makes the text harder to understand
> > > > > > > > for non-native speakers. However, that's not the point you brought up,
> > > > > > > > and even then it is very weak point to make, especially without any
> > > > > > > > actual source for the frequency data. You could also counter that all of
> > > > > > > > these are common loanwords in many languages and are thus easy to
> > > > > > > > understand to non-native speakers anyway.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > Michal
> > > > > > > > >
> > > > > > > > > Documentation/MyFirstContribution.txt | 2 +-
> > > > > > > > > Documentation/MyFirstObjectWalk.txt | 2 +-
> > > > > > > > > Documentation/config/pack.txt | 2 +-
> > > > > > > > > Documentation/git-fast-import.txt | 14 +++++++-------
> > > > > > > > > Documentation/git-fetch.txt | 2 +-
> > > > > > > > > .../technical/hash-function-transition.txt | 2 +-
> > > > > > > > > Documentation/user-manual.txt | 4 ++--
> > > > > > > > > advice.c | 2 +-
> > > > > > > > > builtin/fast-import.c | 2 +-
> > > > > > > > > builtin/pack-objects.c | 2 +-
> > > > > > > > > contrib/coccinelle/README | 2 +-
> > > > > > > > > dir.c | 2 +-
> > > > > > > > > t/perf/p5550-fetch-tags.sh | 2 +-
> > > > > > > > > t/t0008-ignores.sh | 2 +-
> > > > > > > > > t/t0303-credential-external.sh | 2 +-
> > > > > > > > > t/t2020-checkout-detach.sh | 4 ++--
> > > > > > > > > t/t4013-diff-various.sh | 2 +-
> > > > > > > > > t/t5000-tar-tree.sh | 2 +-
> > > > > > > > > t/test-lib-functions.sh | 2 +-
> > > > > > > > > 19 files changed, 27 insertions(+), 27 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/MyFirstContribution.txt
> > > > > > > > > b/Documentation/MyFirstContribution.txt
> > > > > > > > > index af0a9da62e..8372a7e59e 100644
> > > > > > > > > --- a/Documentation/MyFirstContribution.txt
> > > > > > > > > +++ b/Documentation/MyFirstContribution.txt
> > > > > > > > > @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> > > > > > > > > how to show it in the general
> > > > > > > > > command list shown by `git help git` or `git help -a`, which is generated from
> > > > > > > > > `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> > > > > > > > > line above it in alphabetical order. Now, we can add some attributes about the
> > > > > > > > > -command which impacts where it shows up in the aforementioned help
> > > > > > > > > commands. The
> > > > > > > > > +command which affects where it shows up in the aforementioned help
> > > > > > > > > commands. The
> > > > > > > > > top of `command-list.txt` shares some information about what each attribute
> > > > > > > > > means; in those help pages, the commands are sorted according to these
> > > > > > > > > attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> > > > > > > > > diff --git a/Documentation/MyFirstObjectWalk.txt
> > > > > > > > > b/Documentation/MyFirstObjectWalk.txt
> > > > > > > > > index 2d10eea7a9..fd5bb8fb7d 100644
> > > > > > > > > --- a/Documentation/MyFirstObjectWalk.txt
> > > > > > > > > +++ b/Documentation/MyFirstObjectWalk.txt
> > > > > > > > > @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> > > > > > > > > By running your walk with and without the filter, you should find
> > > > > > > > > that the total
> > > > > > > > > object count in each case is identical. You can also time each invocation of
> > > > > > > > > the `walken` subcommand, with and without `omitted` being passed in, to confirm
> > > > > > > > > -to yourself the runtime impact of tracking all omitted objects.
> > > > > > > > > +to yourself the runtime effect of tracking all omitted objects.
> > > > > > > > >
> > > > > > > > > === Changing the Order
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> > > > > > > > > index 3da4ea98e2..00fcc9d7c7 100644
> > > > > > > > > --- a/Documentation/config/pack.txt
> > > > > > > > > +++ b/Documentation/config/pack.txt
> > > > > > > > > @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> > > > > > > > > This cache is used to speed up the writing object phase by not
> > > > > > > > > having to recompute the final delta result once the best match
> > > > > > > > > for all objects is found. Repacking large repositories on machines
> > > > > > > > > - which are tight with memory might be badly impacted by this though,
> > > > > > > > > + which are tight with memory might be badly affected by this though,
> > > > > > > > > especially if this cache pushes the system into swapping.
> > > > > > > > > A value of 0 means no limit. The smallest size of 1 byte may be
> > > > > > > > > used to virtually disable this cache. Defaults to 256 MiB.
> > > > > > > > > diff --git a/Documentation/git-fast-import.txt
> > > > > > > > > b/Documentation/git-fast-import.txt
> > > > > > > > > index 39cfa05b28..c6d8e4e1d7 100644
> > > > > > > > > --- a/Documentation/git-fast-import.txt
> > > > > > > > > +++ b/Documentation/git-fast-import.txt
> > > > > > > > > @@ -58,7 +58,7 @@ OPTIONS
> > > > > > > > > allowing fast-import to access the filesystem outside of the
> > > > > > > > > repository). These options are disabled by default, but can be
> > > > > > > > > allowed by providing this option on the command line. This
> > > > > > > > > - currently impacts only the `export-marks`, `import-marks`, and
> > > > > > > > > + currently affects only the `export-marks`, `import-marks`, and
> > > > > > > > > `import-marks-if-exists` feature commands.
> > > > > > > > > +
> > > > > > > > > Only enable this option if you trust the program generating the
> > > > > > > > > @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
> > > > > > > > >
> > > > > > > > > A `filecopy` command takes effect immediately. Once the source
> > > > > > > > > location has been copied to the destination any future commands
> > > > > > > > > -applied to the source location will not impact the destination of
> > > > > > > > > +applied to the source location will not affect the destination of
> > > > > > > > > the copy.
> > > > > > > > >
> > > > > > > > > `filerename`
> > > > > > > > > @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> > > > > > > > > A `filerename` command takes effect immediately. Once the source
> > > > > > > > > location has been renamed to the destination any future commands
> > > > > > > > > applied to the source location will create new files there and not
> > > > > > > > > -impact the destination of the rename.
> > > > > > > > > +affect the destination of the rename.
> > > > > > > > >
> > > > > > > > > Note that a `filerename` is the same as a `filecopy` followed by a
> > > > > > > > > `filedelete` of the source location. There is a slight performance
> > > > > > > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> > > > > > > > > to be required).
> > > > > > > > > ~~~~~~~~~~
> > > > > > > > > Causes fast-import to print the entire `progress` line unmodified to
> > > > > > > > > its standard output channel (file descriptor 1) when the command is
> > > > > > > > > -processed from the input stream. The command otherwise has no impact
> > > > > > > > > +processed from the input stream. The command otherwise has no effect
> > > > > > > > > on the current import, or on any of fast-import's internal state.
> > > > > > > > >
> > > > > > > > > ....
> > > > > > > > > @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> > > > > > > > > ~~~~~~~~~~
> > > > > > > > > Causes fast-import to print the SHA-1 corresponding to a mark to
> > > > > > > > > stdout or to the file descriptor previously arranged with the
> > > > > > > > > -`--cat-blob-fd` argument. The command otherwise has no impact on the
> > > > > > > > > +`--cat-blob-fd` argument. The command otherwise has no effect on the
> > > > > > > > > current import; its purpose is to retrieve SHA-1s that later commits
> > > > > > > > > might want to refer to in their commit messages.
> > > > > > > > >
> > > > > > > > > @@ -1050,7 +1050,7 @@ this output safely.
> > > > > > > > > ~~~~~~~~~~
> > > > > > > > > Causes fast-import to print a blob to a file descriptor previously
> > > > > > > > > arranged with the `--cat-blob-fd` argument. The command otherwise
> > > > > > > > > -has no impact on the current import; its main purpose is to
> > > > > > > > > +has no effect on the current import; its main purpose is to
> > > > > > > > > retrieve blobs that may be in fast-import's memory but not
> > > > > > > > > accessible from the target repository.
> > > > > > > > >
> > > > > > > > > @@ -1366,7 +1366,7 @@ code considerably.
> > > > > > > > >
> > > > > > > > > The branch LRU builtin to fast-import tends to behave very well, and the
> > > > > > > > > cost of activating an inactive branch is so low that bouncing around
> > > > > > > > > -between branches has virtually no impact on import performance.
> > > > > > > > > +between branches has virtually no effect on import performance.
> > > > > > > > >
> > > > > > > > > Handling Renames
> > > > > > > > > ~~~~~~~~~~~~~~~~
> > > > > > > > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> > > > > > > > > index 9067c2079e..01cf3b3d16 100644
> > > > > > > > > --- a/Documentation/git-fetch.txt
> > > > > > > > > +++ b/Documentation/git-fetch.txt
> > > > > > > > > @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> > > > > > > > > If left to accumulate, these stale references might make performance
> > > > > > > > > worse on big and busy repos that have a lot of branch churn, and
> > > > > > > > > e.g. make the output of commands like `git branch -a --contains
> > > > > > > > > -<commit>` needlessly verbose, as well as impacting anything else
> > > > > > > > > +<commit>` needlessly verbose, as well as affecting anything else
> > > > > > > > > that'll work with the complete set of known references.
> > > > > > > > >
> > > > > > > > > These remote-tracking references can be deleted as a one-off with
> > > > > > > > > diff --git a/Documentation/technical/hash-function-transition.txt
> > > > > > > > > b/Documentation/technical/hash-function-transition.txt
> > > > > > > > > index 7c1630bf83..f4296faffc 100644
> > > > > > > > > --- a/Documentation/technical/hash-function-transition.txt
> > > > > > > > > +++ b/Documentation/technical/hash-function-transition.txt
> > > > > > > > > @@ -42,7 +42,7 @@ mitigations.
> > > > > > > > >
> > > > > > > > > If SHA-1 and its variants were to be truly broken, Git's hash function
> > > > > > > > > could not be considered cryptographically secure any more. This would
> > > > > > > > > -impact the communication of hash values because we could not trust
> > > > > > > > > +affect the communication of hash values because we could not trust
> > > > > > > > > that a given hash value represented the known good version of content
> > > > > > > > > that the speaker intended.
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > > > > > > > > index fd480b8645..33c60c49d7 100644
> > > > > > > > > --- a/Documentation/user-manual.txt
> > > > > > > > > +++ b/Documentation/user-manual.txt
> > > > > > > > > @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
> > > > > > > > >
> > > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > > > > -state without impacting any branches by performing another switch.
> > > > > > > > > +state without affecting any branches by performing another switch.
> > > > > > > > >
> > > > > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > > > > do so (now or later) by using -c with the switch command again. Example:
> > > > > > > > > @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> > > > > > > > > overwritten by the result of
> > > > > > > > > the merge when this combining is done cleanly, or overwritten by a
> > > > > > > > > half-merged results when this combining results in conflicts.
> > > > > > > > > Therefore, if you have uncommitted changes touching the same files as
> > > > > > > > > -the ones impacted by the merge, Git will refuse to proceed. Most of
> > > > > > > > > +the ones affected by the merge, Git will refuse to proceed. Most of
> > > > > > > > > the time, you will want to commit your changes before you can merge,
> > > > > > > > > and if you don't, then linkgit:git-stash[1] can take these changes
> > > > > > > > > away while you're doing the merge, and reapply them afterwards.
> > > > > > > > > diff --git a/advice.c b/advice.c
> > > > > > > > > index 164742305f..9cbbb824a9 100644
> > > > > > > > > --- a/advice.c
> > > > > > > > > +++ b/advice.c
> > > > > > > > > @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> > > > > > > > > "\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/builtin/fast-import.c b/builtin/fast-import.c
> > > > > > > > > index 3afa81cf9a..24f362d2f4 100644
> > > > > > > > > --- a/builtin/fast-import.c
> > > > > > > > > +++ b/builtin/fast-import.c
> > > > > > > > > @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> > > > > > > > > const char *prefix)
> > > > > > > > > * We don't parse most options until after we've seen the set of
> > > > > > > > > * "feature" lines at the start of the stream (which allows the command
> > > > > > > > > * line to override stream data). But we must do an early parse of any
> > > > > > > > > - * command-line options that impact how we interpret the feature lines.
> > > > > > > > > + * command-line options that affect how we interpret the feature lines.
> > > > > > > > > */
> > > > > > > > > for (i = 1; i < argc; i++) {
> > > > > > > > > const char *arg = argv[i];
> > > > > > > > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> > > > > > > > > index 525c2d8552..749bbca241 100644
> > > > > > > > > --- a/builtin/pack-objects.c
> > > > > > > > > +++ b/builtin/pack-objects.c
> > > > > > > > > @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> > > > > > > > > /*
> > > > > > > > > * Mark ourselves as active and see if the next step causes
> > > > > > > > > * us to cycle to another active object. It's important to do
> > > > > > > > > - * this _before_ we loop, because it impacts where we make the
> > > > > > > > > + * this _before_ we loop, because it affects where we make the
> > > > > > > > > * cut, and thus how our total_depth counter works.
> > > > > > > > > * E.g., We may see a partial loop like:
> > > > > > > > > *
> > > > > > > > > diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> > > > > > > > > index f0e80bd7f0..92979ec770 100644
> > > > > > > > > --- a/contrib/coccinelle/README
> > > > > > > > > +++ b/contrib/coccinelle/README
> > > > > > > > > @@ -40,4 +40,4 @@ There are two types of semantic patches:
> > > > > > > > > are ignored for checks, and can be applied using 'make coccicheck-pending'.
> > > > > > > > >
> > > > > > > > > This allows to expose plans of pending large scale refactorings without
> > > > > > > > > - impacting the bad pattern checks.
> > > > > > > > > + affecting the bad pattern checks.
> > > > > > > > > diff --git a/dir.c b/dir.c
> > > > > > > > > index 3474e67e8f..235e26a90e 100644
> > > > > > > > > --- a/dir.c
> > > > > > > > > +++ b/dir.c
> > > > > > > > > @@ -2144,7 +2144,7 @@ static enum path_treatment
> > > > > > > > > treat_path_fast(struct dir_struct *dir,
> > > > > > > > > /*
> > > > > > > > > * We get path_recurse in the first run when
> > > > > > > > > * directory_exists_in_index() returns index_nonexistent. We
> > > > > > > > > - * are sure that new changes in the index does not impact the
> > > > > > > > > + * are sure that new changes in the index does not affect the
> > > > > > > > > * outcome. Return now.
> > > > > > > > > */
> > > > > > > > > return path_recurse;
> > > > > > > > > diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> > > > > > > > > index d0e0e019ea..1fcb98443c 100755
> > > > > > > > > --- a/t/perf/p5550-fetch-tags.sh
> > > > > > > > > +++ b/t/perf/p5550-fetch-tags.sh
> > > > > > > > > @@ -8,7 +8,7 @@ follows.
> > > > > > > > >
> > > > > > > > > The parent repository has a large number of tags which are disconnected from
> > > > > > > > > the rest of history. That makes them candidates for tag-following, but we never
> > > > > > > > > -actually grab them (and thus they will impact each subsequent fetch).
> > > > > > > > > +actually grab them (and thus they will affect each subsequent fetch).
> > > > > > > > >
> > > > > > > > > The child repository is a clone of parent, without the tags, and is at least
> > > > > > > > > one commit behind the parent (meaning that we will fetch one object and then
> > > > > > > > > diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> > > > > > > > > index a594b4aa7d..95daba4000 100755
> > > > > > > > > --- a/t/t0008-ignores.sh
> > > > > > > > > +++ b/t/t0008-ignores.sh
> > > > > > > > > @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> > > > > > > > > # test standard ignores
> > > > > > > > >
> > > > > > > > > # First make sure that the presence of a file in the working tree
> > > > > > > > > -# does not impact results, but that the presence of a file in the
> > > > > > > > > +# does not affect results, but that the presence of a file in the
> > > > > > > > > # index does unless the --no-index option is used.
> > > > > > > > >
> > > > > > > > > for subdir in '' 'a/'
> > > > > > > > > diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> > > > > > > > > index f028fd1418..a9348f655a 100755
> > > > > > > > > --- a/t/t0303-credential-external.sh
> > > > > > > > > +++ b/t/t0303-credential-external.sh
> > > > > > > > > @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> > > > > > > > > eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
> > > > > > > > >
> > > > > > > > > # clean before the test in case there is cruft left
> > > > > > > > > -# over from a previous run that would impact results
> > > > > > > > > +# over from a previous run that would affect results
> > > > > > > > > helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
> > > > > > > > >
> > > > > > > > > helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> > > > > > > > > diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> > > > > > > > > index bc46713a43..568c258c5a 100755
> > > > > > > > > --- a/t/t2020-checkout-detach.sh
> > > > > > > > > +++ b/t/t2020-checkout-detach.sh
> > > > > > > > > @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> > > > > > > > > no SHA-1 ellipsis when not as
> > > > > > > > >
> > > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > > > > - state without impacting any branches by switching back to a branch.
> > > > > > > > > + state without affecting any branches by switching back to a branch.
> > > > > > > > >
> > > > > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > > > > do so (now or later) by using -c with the switch command. Example:
> > > > > > > > > @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> > > > > > > > > print SHA-1 ellipsis when asked
> > > > > > > > >
> > > > > > > > > You are in 'detached HEAD' state. You can look around, make experimental
> > > > > > > > > changes and commit them, and you can discard any commits you make in this
> > > > > > > > > - state without impacting any branches by switching back to a branch.
> > > > > > > > > + state without affecting any branches by switching back to a branch.
> > > > > > > > >
> > > > > > > > > If you want to create a new branch to retain commits you create, you may
> > > > > > > > > do so (now or later) by using -c with the switch command. Example:
> > > > > > > > > diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> > > > > > > > > index 6cca8b84a6..97365a7786 100755
> > > > > > > > > --- a/t/t4013-diff-various.sh
> > > > > > > > > +++ b/t/t4013-diff-various.sh
> > > > > > > > > @@ -109,7 +109,7 @@ test_expect_success setup '
> > > > > > > > > git checkout -f master &&
> > > > > > > > >
> > > > > > > > > # Same merge as master, but with parents reversed. Hide it in a
> > > > > > > > > - # pseudo-ref to avoid impacting tests with --all.
> > > > > > > > > + # pseudo-ref to avoid affecting tests with --all.
> > > > > > > > > commit=$(echo reverse |
> > > > > > > > > git commit-tree -p master^2 -p master^1 master^{tree}) &&
> > > > > > > > > git update-ref REVERSE $commit &&
> > > > > > > > > diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> > > > > > > > > index 7204799a0b..33a6efce2f 100755
> > > > > > > > > --- a/t/t5000-tar-tree.sh
> > > > > > > > > +++ b/t/t5000-tar-tree.sh
> > > > > > > > > @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> > > > > > > > > # Pull the size and date of each entry in a tarfile using the system tar.
> > > > > > > > > #
> > > > > > > > > # We'll pull out only the year from the date; that avoids any question of
> > > > > > > > > -# timezones impacting the result (as long as we keep our test times away from a
> > > > > > > > > +# timezones affecting the result (as long as we keep our test times away from a
> > > > > > > > > # year boundary; our reference times are all in August).
> > > > > > > > > #
> > > > > > > > > # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> > > > > > > > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> > > > > > > > > index 6348e8d733..ff65f86f50 100644
> > > > > > > > > --- a/t/test-lib-functions.sh
> > > > > > > > > +++ b/t/test-lib-functions.sh
> > > > > > > > > @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > # Like "env FOO=BAR some-program", but run inside a subshell, which means
> > > > > > > > > -# it also works for shell functions (though those functions cannot impact
> > > > > > > > > +# it also works for shell functions (though those functions cannot affect
> > > > > > > > > # the environment outside of the test_env invocation).
> > > > > > > > > test_env () {
> > > > > > > > > (
> > > > > > > > > --
> > > > > > > > > 2.17.1
> > > > > > > > >
> > > > > > > > > On Tue, 6 Apr 2021 at 19:06, Varun Varada <varuncvarada@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King <peff@peff.net> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
> > > > > > > > > > >
> > > > > > > > > > > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > > > > > > > > > > problem the word "impact" in itself is not "jargon".
> > > > > > > > > > > >
> > > > > > > > > > > > The word means "to have a strong or marked effect on" (v.) and "a
> > > > > > > > > > > > strong or market influence" (n.) when used figuratively; it is not
> > > > > > > > > > > > synonymous with "affect" and "effect", respectively, as shown even by
> > > > > > > > > > > > all of the entries you've cited. Using it as such is the incorrect
> > > > > > > > > > > > part, so those are the instances I've changed in the diff.
> > > > > > > > > > >
> > > > > > > > > > > Er, is that true? From Michal's definitions:
> > > > > > > > > > >
> > > > > > > > > > > > > From The Collaborative International Dictionary of English v.0.48 :
> > > > > > > > > > > > [...]
> > > > > > > > > > > > > 2. To affect or influence, especially in a significant or
> > > > > > > > > > >
> > > > > > > > > > > It literally uses "affect" to define it. The "especially significant"
> > > > > > > > > > > does not apply to many, but I don't think that makes it necessarily
> > > > > > > > > > > wrong to use impact to mean "affect".
> > > > > > > > > >
> > > > > > > > > > I was drawing attention to the "especially significant" bit and the
> > > > > > > > > > like being there in all the entries. I'm not sure about these
> > > > > > > > > > dictionaries, but the definition is hyperbolic / violent / shocking in
> > > > > > > > > > every reputable dictionary out there: the Oxford English Dictionary,
> > > > > > > > > > Merriam-Webster, and Collins.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Likewise:
> > > > > > > > > > >
> > > > > > > > > > > > > From WordNet (r) 3.0 (2006) :
> > > > > > > > > > > > [...]
> > > > > > > > > > > > > v 1: press or wedge together; pack together
> > > > > > > > > > > > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > > > > > > > > > > > affect, impact, bear upon, bear on, touch on,
> > > > > > > > > > > > > touch]
> > > > > > > > > > >
> > > > > > > > > > > That is likewise listing "impact" and "affect" as synonyms.
> > > > > > > > > > >
> > > > > > > > > > > I do agree the word is over-used in some forms of writing, but I don't
> > > > > > > > > > > find anything at all confusing or wrong about the uses that you changed
> > > > > > > > > > > in your patch. I am a native speaker of English. I'm open to the
> > > > > > > > > > > argument that non-native speakers may be more confused by the word. But
> > > > > > > > > > > this seems like mostly a style preference thing, and I'd generally
> > > > > > > > > > > prefer to leave the contributions and style of the original writers
> > > > > > > > > > > intact unless there is a good reason not to.
> > > > > > > > > >
> > > > > > > > > > I am a native English speaker as well, and there were multiple places
> > > > > > > > > > where I had to think twice about what the sentences mean. I agree with
> > > > > > > > > > your sentiment about leaving stylistic preferences intact, but this is
> > > > > > > > > > actually a semantic one. And given that there is a perfectly good
> > > > > > > > > > alternative that doesn't have this confusion / jargon status, I wanted
> > > > > > > > > > to make the change to improve it, especially where it says that in the
> > > > > > > > > > output of the git command (`git checkout` when in detached HEAD mode).
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Such changes are doubly unwanted in cases like this:
> > > > > > > > > > >
> > > > > > > > > > > > --- a/compat/nedmalloc/malloc.c.h
> > > > > > > > > > > > +++ b/compat/nedmalloc/malloc.c.h
> > > > > > > > > > > > @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> > > > > > > > > > > > #endif /* (FOOTERS && !INSECURE) */
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > -/* In gcc, use __builtin_expect to minimize impact of checks */
> > > > > > > > > > > > +/* In gcc, use __builtin_expect to minimize affect of checks */
> > > > > > > > > > > > #if !INSECURE
> > > > > > > > > > > > #if defined(__GNUC__) && __GNUC__ >= 3
> > > > > > > > > > > > #define RTCHECK(e) __builtin_expect(e, 1)
> > > > > > > > > > >
> > > > > > > > > > > where the text is imported from another project, and we'd prefer to stay
> > > > > > > > > > > as close to their version as possible (e.g., to avoid unnecessary
> > > > > > > > > > > conflicts when pulling in new versions).
> > > > > > > > > >
> > > > > > > > > > That's fair; I wasn't aware that this was being pulled directly from
> > > > > > > > > > another project. I can change this back.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Also, this one should be "effect" anyway, as it is a noun.
> > > > > > > > > >
> > > > > > > > > > This seems to have slipped through, as I used a text search tool.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > -Peff
>
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-11 10:43 ` Michal Suchánek
@ 2021-05-11 13:22 ` Junio C Hamano
2021-05-12 3:02 ` Felipe Contreras
2021-05-12 2:59 ` Felipe Contreras
1 sibling, 1 reply; 68+ messages in thread
From: Junio C Hamano @ 2021-05-11 13:22 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Varun Varada, Jeff King, git
Michal Suchánek <msuchanek@suse.de> writes:
> Since you can look up the meaning of the word in a general purpose
> dictionary it should be an acceptable use even if it's less commonly
> used in some other English-speaking parts of the world.
> ...
> They are not confusing in the way they are used. That is 'does not
> impact' in the maning 'has no or negligible effect', and especially in
> the cases where the degree of effect is not considered and only there
> being an effect or not is discussed there is no room for confusion.
> ...
> ...
> This topic somewhat interests me so I was continuing this discussion
> in the hope that you either provide a specific very confusing use of the
> word impact in the documentation that triggered creating this patch or
> some solid evidence that the general use of word 'impact' as synonym for
> affect/effect is in some way problematic but niether happened.
>
> I think this topic has been discussed sufficiently and there is nothing
> more to add.
Thanks.
As you said, lack of a specific example of what is universally
confusing, or at least confusing to a not-so-insignificant part of
the readership, was why this change didn't gain much support. There
might be one or two such places where the updated text does read
better, but it is not a very good use of reviewers' time to find
such needles in 700+ line haystack of a patch.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-06 9:24 ` Michal Suchánek
2021-04-06 19:36 ` Varun Varada
@ 2021-05-11 19:21 ` Felipe Contreras
2021-05-11 19:57 ` Michal Suchánek
1 sibling, 1 reply; 68+ messages in thread
From: Felipe Contreras @ 2021-05-11 19:21 UTC (permalink / raw)
To: Michal Suchánek, Varun Varada; +Cc: git
Michal Suchánek wrote:
> On Mon, Apr 05, 2021 at 04:48:58PM -0500, Varun Varada wrote:
> > There are a bunch of places in the code/docs which use the word "impact"
> > incorrectly. This is especially true of places where it says "will not
> > impact", which suggests that it might have an effect, albeit not as
> > strong of a one. This commit replaces all of these with their
> > appropriate alternative so that the docs not only does not use jargon,
> > but are also unambiguous.
>
> Hello,
>
> while using "will not impact" in an incorrect or unclear way may be a
> problem the word "impact" in itself is not "jargon".
From Merriam-Webster:
jargon _noun_
: obscure and often pretentious language marked by circumlocutions and
long words
> If you are concerned about correctness and clarity of the documentation please
> avoid spreading misinformation.
Under certain definition of "jaron" Varun's statement would be
incorrect, but not under all definitions. If you use the definition
I stated above, "impact" can be considered jargon, because it's a bit
obscure language.
Ultimately it doesn't matter if it's jargon or not, only that we have
better alternatives.
> Thanks
>
> Michal
Michal, can you please remove quoted lines you are not replying to?
Those 762 extra lines make it harder for some of us to read the thread.
We don't have email guidelines, but if we did, that certain would be one
of the points.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-11 19:21 ` Felipe Contreras
@ 2021-05-11 19:57 ` Michal Suchánek
2021-05-12 3:09 ` Felipe Contreras
0 siblings, 1 reply; 68+ messages in thread
From: Michal Suchánek @ 2021-05-11 19:57 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, git
On Tue, May 11, 2021 at 02:21:43PM -0500, Felipe Contreras wrote:
> Michal Suchánek wrote:
> > On Mon, Apr 05, 2021 at 04:48:58PM -0500, Varun Varada wrote:
> > > There are a bunch of places in the code/docs which use the word "impact"
> > > incorrectly. This is especially true of places where it says "will not
> > > impact", which suggests that it might have an effect, albeit not as
> > > strong of a one. This commit replaces all of these with their
> > > appropriate alternative so that the docs not only does not use jargon,
> > > but are also unambiguous.
> >
> > Hello,
> >
> > while using "will not impact" in an incorrect or unclear way may be a
> > problem the word "impact" in itself is not "jargon".
>
> From Merriam-Webster:
>
> jargon _noun_
> : obscure and often pretentious language marked by circumlocutions and
> long words
>
> > If you are concerned about correctness and clarity of the documentation please
> > avoid spreading misinformation.
>
> Under certain definition of "jaron" Varun's statement would be
> incorrect, but not under all definitions. If you use the definition
> I stated above, "impact" can be considered jargon, because it's a bit
> obscure language.
Do you have any frequency data that supports your claim that the word
'impact' is obscure?
In my view it's common.
> Ultimately it doesn't matter if it's jargon or not, only that we have
> better alternatives.
'better' under what metric?
As already stated if we replaced words with synonyms solely on the basis
that some people find one word more fitting or commonly used we could
end up in a situation that we change between two wordings back and forth
because people from different parts of the world find different words
more fitting and common.
The bar for change should be that the word as used is very unfitting or
unintelligible.
Thanks
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-06 19:36 ` Varun Varada
2021-04-06 23:01 ` Jeff King
@ 2021-05-11 19:59 ` Felipe Contreras
2021-05-11 20:25 ` Michal Suchánek
1 sibling, 1 reply; 68+ messages in thread
From: Felipe Contreras @ 2021-05-11 19:59 UTC (permalink / raw)
To: Varun Varada, Michal Suchánek; +Cc: git
Varun Varada wrote:
> On Tue, 6 Apr 2021 at 04:24, Michal Suchánek <msuchanek@suse.de> wrote:
> > while using "will not impact" in an incorrect or unclear way may be a
> > problem the word "impact" in itself is not "jargon".
>
> The word means "to have a strong or marked effect on" (v.) and "a
> strong or market influence" (n.) when used figuratively; it is not
> synonymous with "affect" and "effect", respectively, as shown even by
> all of the entries you've cited. Using it as such is the incorrect
> part, so those are the instances I've changed in the diff.
There are two ways impact can be used as a verb: transitive and
intransitive, but git doesn't seem to be using the intransitive form. In
the transitive form it usually means to strike "the car impacted the
tree". But it can also mean to have a desired effect "reducing CO2
emissions impacted climate change".
None of these are used in the documentation, we have things like:
the index does not impact the outcome
Which is clearly wrong (unless we are talking about possitive outcome of
the outcome, which makes no sense).
As a noun it can mean a siginificant or major effect: "the impact of
science".
However, the documentation is not using it that way:
the runtime impact of tracking all omitted objects
The noun usage is less wrong than the verb usage, but it's still wrong.
The verb usage could be corrected by changing "the index does not
impact", to "the index does not have an impact on".
But why bother? The word "affect" is a much superior choice.
I'm in favor of this change.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-11 19:59 ` Felipe Contreras
@ 2021-05-11 20:25 ` Michal Suchánek
2021-05-11 21:38 ` Varun Varada
2021-05-12 3:21 ` Felipe Contreras
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-05-11 20:25 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, git
On Tue, May 11, 2021 at 02:59:32PM -0500, Felipe Contreras wrote:
> Varun Varada wrote:
> > On Tue, 6 Apr 2021 at 04:24, Michal Suchánek <msuchanek@suse.de> wrote:
> > > while using "will not impact" in an incorrect or unclear way may be a
> > > problem the word "impact" in itself is not "jargon".
> >
> > The word means "to have a strong or marked effect on" (v.) and "a
> > strong or market influence" (n.) when used figuratively; it is not
> > synonymous with "affect" and "effect", respectively, as shown even by
> > all of the entries you've cited. Using it as such is the incorrect
> > part, so those are the instances I've changed in the diff.
>
> There are two ways impact can be used as a verb: transitive and
> intransitive, but git doesn't seem to be using the intransitive form. In
> the transitive form it usually means to strike "the car impacted the
> tree". But it can also mean to have a desired effect "reducing CO2
> emissions impacted climate change".
I don't know where you find the 'desired' effect meaning. Certainly none
of the dictionaries I consulted at random provides such definition.
>
> None of these are used in the documentation, we have things like:
>
> the index does not impact the outcome
>
> Which is clearly wrong (unless we are talking about possitive outcome of
> the outcome, which makes no sense).
It is not clearly wrong. To me it makes perfect sense. If you want to
claim it's wrong please provide a source for your claim. Otherwise it's
just matter of different opinions of more fitting formulation.
>
> As a noun it can mean a siginificant or major effect: "the impact of
> science".
>
> However, the documentation is not using it that way:
>
> the runtime impact of tracking all omitted objects
>
> The noun usage is less wrong than the verb usage, but it's still wrong.
Why is that wrong?
How did you infer that the effect is insignificant or minor?
In fact while some dictionaries list 'impact' as 'have strong effect'
the Oxford dicrionary lists is as simply synonymous to 'affect'.
> The verb usage could be corrected by changing "the index does not
> impact", to "the index does not have an impact on".
Why is that change needed at all?
> But why bother? The word "affect" is a much superior choice.
Why bother with a chenge at all?
Thanks
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-11 20:25 ` Michal Suchánek
@ 2021-05-11 21:38 ` Varun Varada
2021-05-12 3:43 ` Felipe Contreras
2021-05-12 3:21 ` Felipe Contreras
1 sibling, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-05-11 21:38 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Felipe Contreras, git
On Tue, 11 May 2021 at 15:25, Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Tue, May 11, 2021 at 02:59:32PM -0500, Felipe Contreras wrote:
> > Varun Varada wrote:
> > > On Tue, 6 Apr 2021 at 04:24, Michal Suchánek <msuchanek@suse.de> wrote:
> > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > problem the word "impact" in itself is not "jargon".
> > >
> > > The word means "to have a strong or marked effect on" (v.) and "a
> > > strong or market influence" (n.) when used figuratively; it is not
> > > synonymous with "affect" and "effect", respectively, as shown even by
> > > all of the entries you've cited. Using it as such is the incorrect
> > > part, so those are the instances I've changed in the diff.
> >
> > There are two ways impact can be used as a verb: transitive and
> > intransitive, but git doesn't seem to be using the intransitive form. In
> > the transitive form it usually means to strike "the car impacted the
> > tree". But it can also mean to have a desired effect "reducing CO2
> > emissions impacted climate change".
>
> I don't know where you find the 'desired' effect meaning. Certainly none
> of the dictionaries I consulted at random provides such definition.
>
> >
> > None of these are used in the documentation, we have things like:
> >
> > the index does not impact the outcome
> >
> > Which is clearly wrong (unless we are talking about possitive outcome of
> > the outcome, which makes no sense).
>
> It is not clearly wrong. To me it makes perfect sense. If you want to
> claim it's wrong please provide a source for your claim. Otherwise it's
> just matter of different opinions of more fitting formulation.
You agreed that the word "impact" means to "significantly affect". The
idea of whether something is *significantly* affected, as opposed to
conveying the idea that something is affected at all, only arises in
situations where degrees of an influence are possible; that's not the
case in any of the examples my change is editing (except for the one I
conceded where it says "badly impacted"). Assuming that a reader would
know which of those involve degrees of influence are possible and
which aren't, even if every reader of the documentation/command output
was familiar, is entirely unnecessary. That's the point here: there is
this point of confusion that is entirely avoidable with a simple
one-word change.
Re: your point about me not pointing out specific examples: the
command output for detached HEAD state reads "you can discard any
commits you make in this state without impacting any branches by
switching back to a branch". I'm incredibly passionate about this
example. Here, the user is left to think, "wait...so this will not
impact (significantly affect) any branches, but will it affect them?
As in, are there side effects that I should be aware of? Where do I go
to find out what they are?" All of this mental energy is completely
unnecessary. Mind you, this is regarding discarding commits, which is
a destructive action.
You might feel that this is just one example that might need fixing,
but I assure you, I've analysed all the other examples and they all
have similar problems. It's entirely unnecessary to have this
confusion.
>
> >
> > As a noun it can mean a siginificant or major effect: "the impact of
> > science".
> >
> > However, the documentation is not using it that way:
> >
> > the runtime impact of tracking all omitted objects
> >
> > The noun usage is less wrong than the verb usage, but it's still wrong.
>
> Why is that wrong?
>
> How did you infer that the effect is insignificant or minor?
No one did, and that's the point. All impacts are effects, but not all
effects are impacts. You yourself acknowledged that there is a
prevalent tendency to hyperbolize, and the fact that one doesn't know
which it is in this case (or frankly any of the other cases my commit
touches) is problematic. This kind of confusion surely doesn't belong
in technical documentation. And if it is indeed an "impact", where is
that conveyed? What's so notable about the effect on the runtime?
That's the point.
>
> In fact while some dictionaries list 'impact' as 'have strong effect'
> the Oxford dicrionary lists is as simply synonymous to 'affect'.
>
> > The verb usage could be corrected by changing "the index does not
> > impact", to "the index does not have an impact on".
>
> Why is that change needed at all?
>
> > But why bother? The word "affect" is a much superior choice.
>
> Why bother with a chenge at all?
It seems like you already previously agreed with the premise that the
word means "a significant effect" or "to significantly affect". I
understand and appreciate your thoroughness to scrutinize changes to
the repo, but I'm frankly surprised that such a small change is
attracting such fierce debate. This is meant to be a change that is
probably one of the easiest ones to decide on: it only consists of
one-word changes that don't change functionality, yet undeniably
reduce confusion.
Re: your previous point about linguistic authorities: yes, there is no
authority on usage, but therein lies my point. This doesn't even need
to rise to the domain of usage, because it is squarely within the
realm of semantics. Words mean something, and we all use dictionaries
to learn about / confirm those meanings. Insofar as all the major
dictionaries cite the word as "a significant effect" / "to affect
significantly", that semantic concept doesn't belong in the cases
where I've made changes. And if it does, then those need to be
clarified (because that's where the real confusion/ambiguity is).
I.e., it's not "why is not every case a significant effect?", but "why
are some cases a significant effect?"
>
> Thanks
>
> Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-06 23:01 ` Jeff King
2021-04-07 0:06 ` Varun Varada
@ 2021-05-12 2:24 ` Felipe Contreras
1 sibling, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 2:24 UTC (permalink / raw)
To: Jeff King, Varun Varada; +Cc: Michal Suchánek, git
Jeff King wrote:
> On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada wrote:
>
> > > while using "will not impact" in an incorrect or unclear way may be a
> > > problem the word "impact" in itself is not "jargon".
> >
> > The word means "to have a strong or marked effect on" (v.) and "a
> > strong or market influence" (n.) when used figuratively; it is not
> > synonymous with "affect" and "effect", respectively, as shown even by
> > all of the entries you've cited. Using it as such is the incorrect
> > part, so those are the instances I've changed in the diff.
>
> Er, is that true? From Michal's definitions:
>
> > > From The Collaborative International Dictionary of English v.0.48 :
> > [...]
> > > 2. To affect or influence, especially in a significant or
>
> It literally uses "affect" to define it. The "especially significant"
> does not apply to many, but I don't think that makes it necessarily
> wrong to use impact to mean "affect".
It's not necessarily wrong, but it's also not quite right.
You can say "the financial crisis impacted Jeff Bezos", because he was
affected, but was he *especially* affected? Nah. On the other hand "the
financial crisis affected Jeff Bezos" is something much less
problematic.
> Likewise:
>
> > > From WordNet (r) 3.0 (2006) :
> > [...]
> > > v 1: press or wedge together; pack together
> > > 2: have an effect upon; "Will the new rules affect me?" [syn:
> > > affect, impact, bear upon, bear on, touch on,
> > > touch]
>
> That is likewise listing "impact" and "affect" as synonyms.
A synonym can be a word with nearly the same meaning in some senses. Not
necessarily exactly the same meaning in all senses.
> I do agree the word is over-used in some forms of writing, but I don't
> find anything at all confusing or wrong about the uses that you changed
> in your patch.
It doesn't need to be confusing to be changed. Most of the changes in
the code are not because the original version is confusing, but because
the new version is simply better.
Do you have any instance in which a sentence with "impact" is *better*
than whith one with affect/effect?
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-28 8:58 ` Michal Suchánek
2021-04-28 18:15 ` Varun Varada
@ 2021-05-12 2:34 ` Felipe Contreras
1 sibling, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 2:34 UTC (permalink / raw)
To: Michal Suchánek, Varun Varada; +Cc: Jeff King, git
Michal Suchánek wrote:
> On Tue, Apr 27, 2021 at 07:39:57PM -0500, Varun Varada wrote:
> > Here's the updated diff:
>
> As already said multiple general purpose dictionaries recognize '(have)
> strong effect' as the meaning of 'impact', in some cases even the most
> common meaning.
Having a strong effect is not the same as having an effect.
> In case you have some issue with the word 'jargon' Merriam-Webster gives
> this definition:
...
> 2: obscure and often pretentious language marked by circumlocutions and long words
...
> which the word 'impact' does not fulfill.
That's a value judgement.
The word "impact" as it's used in the git documentation can certainly be
considered "obsucre language".
> Further, you would rarely discuss and document an effect that is
> negligible so in vast majority of cases '(have) strong effect' (ie
> 'impact') is synonymous to 'affect' and 'affect', respectively.
Nobody is saying the effect is negligible.
An effect can be noticeable, yet not especial in any way.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-28 18:49 ` Michal Suchánek
2021-04-30 1:51 ` Varun Varada
@ 2021-05-12 2:38 ` Felipe Contreras
1 sibling, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 2:38 UTC (permalink / raw)
To: Michal Suchánek, Varun Varada; +Cc: Jeff King, git
Michal Suchánek wrote:
> At any rate 'strong' is always relative. Unless you have a specific
> reference of average strenth anything can be considered strong or weak
> depending on point of view.
Yes, but "impact" implies the effect is strong, "affect" on the other
hand does not imply the effect is weak, merely that there is some (could
be strong, weak, or nominal).
The safe choice is obvious.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-10 17:35 ` Michal Suchánek
2021-05-10 18:37 ` Varun Varada
@ 2021-05-12 2:48 ` Felipe Contreras
1 sibling, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 2:48 UTC (permalink / raw)
To: Michal Suchánek, Varun Varada; +Cc: Jeff King, git
Michal Suchánek wrote:
> On Mon, May 10, 2021 at 12:19:05PM -0500, Varun Varada wrote:
> It refers to redundant changes to the codebase which do not improve it in
> any way.
This is not the codebase, and what does or not "improve in any way"
the status quo is relative to who you ask.
> > As for there being no distinction, there's no gradation within the
> > semantics of this context; this doesn't change the semantics of the
> > words themselves. Using "impact" when what is meant is just "effect"
> > or "affect" is incorrect in all such instances.
>
> That's your opinion not shared by the authors of the text.
How do you know? Have you asked them?
Just because person A wrote text X doesn't necessarily mean they think
their version is superior to any and all future suggestions of
improvment.
> The authority you refer to is MIT which is known for technical
> brilliance but not as authority on linguistics.
The MIT hosted Noam Chomsky for many decadates. Are you really arguing
Noam Chomsky is not an authority in linguistics?
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-11 10:43 ` Michal Suchánek
2021-05-11 13:22 ` Junio C Hamano
@ 2021-05-12 2:59 ` Felipe Contreras
1 sibling, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 2:59 UTC (permalink / raw)
To: Michal Suchánek, Varun Varada; +Cc: Jeff King, git
Michal Suchánek wrote:
> Also there is no single authority on the English language. The language
> is spoken in multiple distinct countries, and even within one country
> there is some variation. It also evolves over time.
And this is precisely the reason why you target the least common
denominator.
Do you have **any** instance in which the sentence with "affect" reads
worse than with "impact"?
> Since you can look up the meaning of the word in a general purpose
> dictionary it should be an acceptable use even if it's less commonly
> used in some other English-speaking parts of the world.
If you are writing classic prose, and most of your audience needs to use
the dictionary to understand what you meant, you have failed.
> > > If you do wholesale word replacement in the project for no good reason
> > > it only makes working with the project history harder.
> >
> > I'm not sure I understand the sentiment here. As in, the Git history
> > will be polluted? Because the "git blame" command will only show
> > changes for the lines where I changed the single words.
>
> Yes, it will be polluted. And since we have an opinion of another native
> English speaker that the use of 'impact' as synonym for affect/effect is
> fine this is clearly a matter of opinion.
It's not just native English speakers that read the English
documentation.
> This topic somewhat interests me so I was continuing this discussion
> in the hope that you either provide a specific very confusing use of the
> word impact in the documentation that triggered creating this patch or
> some solid evidence that the general use of word 'impact' as synonym for
> affect/effect is in some way problematic but niether happened.
This is not how improvements work.
We have two options: $a, and $b. You argue that $a doesn't really
provide any advantages over $b (although it has been clearly demonstrated
that it does). But you are not providing any advantage of $b over $a
either.
Let's turn the tables around; do **you** have any evidence that "impact"
is superior to "affect" in **any** instance?
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-11 13:22 ` Junio C Hamano
@ 2021-05-12 3:02 ` Felipe Contreras
0 siblings, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 3:02 UTC (permalink / raw)
To: Junio C Hamano, Michal Suchánek; +Cc: Varun Varada, Jeff King, git
Junio C Hamano wrote:
> As you said, lack of a specific example of what is universally
> confusing, or at least confusing to a not-so-insignificant part of
> the readership, was why this change didn't gain much support.
The original version doesn't necessarily need to be confusing.
It's sufficient that the new version is better.
> There might be one or two such places where the updated text does read
> better, but it is not a very good use of reviewers' time to find such
> needles in 700+ line haystack of a patch.
As a reviewer I will decide where I to allocate my reviewer's time,
because it's my time.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-11 19:57 ` Michal Suchánek
@ 2021-05-12 3:09 ` Felipe Contreras
2021-05-12 4:11 ` Michal Suchánek
0 siblings, 1 reply; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 3:09 UTC (permalink / raw)
To: Michal Suchánek, Felipe Contreras; +Cc: Varun Varada, git
Michal Suchánek wrote:
> On Tue, May 11, 2021 at 02:21:43PM -0500, Felipe Contreras wrote:
> > Michal Suchánek wrote:
> > > If you are concerned about correctness and clarity of the documentation please
> > > avoid spreading misinformation.
> >
> > Under certain definition of "jaron" Varun's statement would be
> > incorrect, but not under all definitions. If you use the definition
> > I stated above, "impact" can be considered jargon, because it's a bit
> > obscure language.
>
> Do you have any frequency data that supports your claim that the word
> 'impact' is obscure?
This is not how logic works.
If I don't have frequency data that supports $x, but you have no
frequency data that supports !$x, then we return to the default position;
we don't know if $x is true or not.
Do **you** have any frequency data that supports the negative claim that
the word "impact" is not obscure?
> The bar for change should be that the word as used is very unfitting or
> unintelligible.
No. The bar is that **nobody** have any problem with "affect", and some
people have a problem with "impact".
Do you have any problem with "affect"?
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-11 20:25 ` Michal Suchánek
2021-05-11 21:38 ` Varun Varada
@ 2021-05-12 3:21 ` Felipe Contreras
1 sibling, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 3:21 UTC (permalink / raw)
To: Michal Suchánek, Felipe Contreras; +Cc: Varun Varada, git
Michal Suchánek wrote:
> On Tue, May 11, 2021 at 02:59:32PM -0500, Felipe Contreras wrote:
> > Varun Varada wrote:
> > > On Tue, 6 Apr 2021 at 04:24, Michal Suchánek <msuchanek@suse.de> wrote:
> > > > while using "will not impact" in an incorrect or unclear way may be a
> > > > problem the word "impact" in itself is not "jargon".
> > >
> > > The word means "to have a strong or marked effect on" (v.) and "a
> > > strong or market influence" (n.) when used figuratively; it is not
> > > synonymous with "affect" and "effect", respectively, as shown even by
> > > all of the entries you've cited. Using it as such is the incorrect
> > > part, so those are the instances I've changed in the diff.
> >
> > There are two ways impact can be used as a verb: transitive and
> > intransitive, but git doesn't seem to be using the intransitive form. In
> > the transitive form it usually means to strike "the car impacted the
> > tree". But it can also mean to have a desired effect "reducing CO2
> > emissions impacted climate change".
>
> I don't know where you find the 'desired' effect meaning. Certainly none
> of the dictionaries I consulted at random provides such definition.
You yourself consulted Merriam-Webster [1]:
impact _verb_
: to have a direct effect or impact on : impinge on
Did you not? [2]
> > None of these are used in the documentation, we have things like:
> >
> > the index does not impact the outcome
> >
> > Which is clearly wrong (unless we are talking about possitive outcome of
> > the outcome, which makes no sense).
>
> It is not clearly wrong. To me it makes perfect sense. If you want to
> claim it's wrong please provide a source for your claim.
Merriam-Webster [1].
> > As a noun it can mean a siginificant or major effect: "the impact of
> > science".
> >
> > However, the documentation is not using it that way:
> >
> > the runtime impact of tracking all omitted objects
> >
> > The noun usage is less wrong than the verb usage, but it's still wrong.
>
> Why is that wrong?
Because it's not a "a significant or major effect" [1].
> How did you infer that the effect is insignificant or minor?
I did not.
If I claim temperature $x is not hot, that doesn't mean I'm claiming
it's cold.
> In fact while some dictionaries list 'impact' as 'have strong effect'
> the Oxford dicrionary lists is as simply synonymous to 'affect'.
Synonymous doesn't mean equal. In fact, the Oxford dictionary defines
"impact" as [3]:
the powerful effect that something has on somebody/something
Note: *powerful*.
> > But why bother? The word "affect" is a much superior choice.
>
> Why bother with a chenge at all?
Because it's better.
Do you have any evidence that it's worse?
[1] https://www.merriam-webster.com/dictionary/impact
[2] https://lore.kernel.org/git/20210406092440.GZ6564@kitsune.suse.cz/
[3] https://www.oxfordlearnersdictionaries.com/definition/english/impact_1
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-11 21:38 ` Varun Varada
@ 2021-05-12 3:43 ` Felipe Contreras
2021-05-12 4:09 ` Michal Suchánek
0 siblings, 1 reply; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 3:43 UTC (permalink / raw)
To: Varun Varada, Michal Suchánek; +Cc: Felipe Contreras, git
Varun Varada wrote:
> Re: your point about me not pointing out specific examples: the
> command output for detached HEAD state reads "you can discard any
> commits you make in this state without impacting any branches by
> switching back to a branch". I'm incredibly passionate about this
> example. Here, the user is left to think, "wait...so this will not
> impact (significantly affect) any branches, but will it affect them?
> As in, are there side effects that I should be aware of? Where do I go
> to find out what they are?" All of this mental energy is completely
> unnecessary. Mind you, this is regarding discarding commits, which is
> a destructive action.
Completely agree.
I'm not a native speaker of English, but nowadays I use English more
than any other language, and when I read *impact* I read alarm bells.
First I'm reminded of "brace for impact", which something nobody should
take lightly (native speaker or not), and when I search for "impact" on
IMDB the first result I find is Deep Impact [1]. Not something bland.
Maybe my understanding of the word has been tainted by my experience,
sure...
But I'm still waiting for anybody to explain what's wrong with "affect".
> > > But why bother? The word "affect" is a much superior choice.
> >
> > Why bother with a chenge at all?
>
> It seems like you already previously agreed with the premise that the
> word means "a significant effect" or "to significantly affect". I
> understand and appreciate your thoroughness to scrutinize changes to
> the repo, but I'm frankly surprised that such a small change is
> attracting such fierce debate. This is meant to be a change that is
> probably one of the easiest ones to decide on: it only consists of
> one-word changes that don't change functionality, yet undeniably
> reduce confusion.
When I started contributing to the git project more than 10 years ago I
noticed precisely the same thing.
It is a paradox called "the bikeshedding effect". When you contribute a
complex and convoluted change it's easier to get it in because few people
can object (as few people can understand it). But when you contribute a
change as simple as changing the color of something, then *everyone* can
opine (literally).
That's why the simplest changes tend to be the most difficult.
Additionally in my opinion the git project has a language problem, but
that's a separate subject.
> Re: your previous point about linguistic authorities: yes, there is no
> authority on usage, but therein lies my point. This doesn't even need
> to rise to the domain of usage, because it is squarely within the
> realm of semantics. Words mean something, and we all use dictionaries
> to learn about / confirm those meanings. Insofar as all the major
> dictionaries cite the word as "a significant effect" / "to affect
> significantly", that semantic concept doesn't belong in the cases
> where I've made changes. And if it does, then those need to be
> clarified (because that's where the real confusion/ambiguity is).
> I.e., it's not "why is not every case a significant effect?", but "why
> are some cases a significant effect?"
I often find it's easier to flip the problem around (from Karl Popper's
falsification principle).
It should not be your duty to prove that all swans are white (which is
impossible), it's the duty of the skeptics to prove that a single swan
is black.
I haven't seen a single person in this thread pointing out what's wrong
with "affect".
Cheers.
[1] https://www.imdb.com/title/tt0120647/
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 3:43 ` Felipe Contreras
@ 2021-05-12 4:09 ` Michal Suchánek
2021-05-12 5:13 ` Felipe Contreras
0 siblings, 1 reply; 68+ messages in thread
From: Michal Suchánek @ 2021-05-12 4:09 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, git
On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:
> Varun Varada wrote:
>
> > Re: your point about me not pointing out specific examples: the
> > command output for detached HEAD state reads "you can discard any
> > commits you make in this state without impacting any branches by
> > switching back to a branch". I'm incredibly passionate about this
> > example. Here, the user is left to think, "wait...so this will not
> > impact (significantly affect) any branches, but will it affect them?
> > As in, are there side effects that I should be aware of? Where do I go
> > to find out what they are?" All of this mental energy is completely
> > unnecessary. Mind you, this is regarding discarding commits, which is
> > a destructive action.
>
> Completely agree.
>
> I'm not a native speaker of English, but nowadays I use English more
> than any other language, and when I read *impact* I read alarm bells.
>
> First I'm reminded of "brace for impact", which something nobody should
> take lightly (native speaker or not), and when I search for "impact" on
> IMDB the first result I find is Deep Impact [1]. Not something bland.
> Maybe my understanding of the word has been tainted by my experience,
> sure...
>
> But I'm still waiting for anybody to explain what's wrong with "affect".
>
> > > > But why bother? The word "affect" is a much superior choice.
> > >
> > > Why bother with a chenge at all?
> >
> > It seems like you already previously agreed with the premise that the
> > word means "a significant effect" or "to significantly affect". I
> > understand and appreciate your thoroughness to scrutinize changes to
> > the repo, but I'm frankly surprised that such a small change is
> > attracting such fierce debate. This is meant to be a change that is
> > probably one of the easiest ones to decide on: it only consists of
> > one-word changes that don't change functionality, yet undeniably
> > reduce confusion.
>
> When I started contributing to the git project more than 10 years ago I
> noticed precisely the same thing.
>
> It is a paradox called "the bikeshedding effect". When you contribute a
> complex and convoluted change it's easier to get it in because few people
> can object (as few people can understand it). But when you contribute a
> change as simple as changing the color of something, then *everyone* can
> opine (literally).
You forget that what you are doing right now is bikeshedding after the
fact.
You can use 'affect' or 'impact' and it generally conveys the same
meaning. Some speakers find 'affect' more natural. Clearly other
speakers such as authors of the changes that use the word 'impact' find
'impact' more natural. If we give in to the desire to pick the more
natural sounding synonym we will get endless back and forth of patches
changing one synonym to another.
Thanks
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 3:09 ` Felipe Contreras
@ 2021-05-12 4:11 ` Michal Suchánek
2021-05-12 5:22 ` Felipe Contreras
2021-05-12 16:39 ` Varun Varada
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-05-12 4:11 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, git
On Tue, May 11, 2021 at 10:09:56PM -0500, Felipe Contreras wrote:
> Michal Suchánek wrote:
> > On Tue, May 11, 2021 at 02:21:43PM -0500, Felipe Contreras wrote:
> > > Michal Suchánek wrote:
>
> > > > If you are concerned about correctness and clarity of the documentation please
> > > > avoid spreading misinformation.
> > >
> > > Under certain definition of "jaron" Varun's statement would be
> > > incorrect, but not under all definitions. If you use the definition
> > > I stated above, "impact" can be considered jargon, because it's a bit
> > > obscure language.
> >
> > Do you have any frequency data that supports your claim that the word
> > 'impact' is obscure?
>
> This is not how logic works.
>
> If I don't have frequency data that supports $x, but you have no
> frequency data that supports !$x, then we return to the default position;
> we don't know if $x is true or not.
>
> Do **you** have any frequency data that supports the negative claim that
> the word "impact" is not obscure?
I don't need that data. You are proposing a change so it is your duty to
support your claim that the change is worthwhile.
Otherwise it's a change just for the sake of change.
>
> > The bar for change should be that the word as used is very unfitting or
> > unintelligible.
>
> No. The bar is that **nobody** have any problem with "affect", and some
> people have a problem with "impact".
And that's established how, specifically?
Thanks
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 4:09 ` Michal Suchánek
@ 2021-05-12 5:13 ` Felipe Contreras
2021-05-12 6:47 ` Michal Suchánek
0 siblings, 1 reply; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 5:13 UTC (permalink / raw)
To: Michal Suchánek, Felipe Contreras; +Cc: Varun Varada, git
Michal Suchánek wrote:
> On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:
> > It is a paradox called "the bikeshedding effect". When you contribute a
> > complex and convoluted change it's easier to get it in because few people
> > can object (as few people can understand it). But when you contribute a
> > change as simple as changing the color of something, then *everyone* can
> > opine (literally).
>
> You forget that what you are doing right now is bikeshedding after the
> fact.
Except that's not what I'm doing.
> You can use 'affect' or 'impact' and it generally conveys the same
> meaning.
That's clearly *your* opinion, but that's not my opinon.
I'm not arguing between blue and red; I'm arguing between water-based and
lead-based paint.
The difference may not matter to you, but it matters to me.
If it's bikeshedding to you, and it "gnerally conveys the same meaning",
why are you arguing against?
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 4:11 ` Michal Suchánek
@ 2021-05-12 5:22 ` Felipe Contreras
2021-05-12 16:39 ` Varun Varada
1 sibling, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 5:22 UTC (permalink / raw)
To: Michal Suchánek, Felipe Contreras; +Cc: Varun Varada, git
Michal Suchánek wrote:
> On Tue, May 11, 2021 at 10:09:56PM -0500, Felipe Contreras wrote:
> > Do **you** have any frequency data that supports the negative claim that
> > the word "impact" is not obscure?
>
> I don't need that data.
> You are proposing a change so it is your duty to support your claim
> that the change is worthwhile.
I am not the one proposing the change, but it has been established that
at least two people find the change worthwhile, and many dictionaries
find "affect" less problematic than "impact".
You (and others) don't find the change worthline, fair enough.
But you also can't find anything wrong with the proposed change.
So let me try to explain the situation programatically:
1. ($a > $b) * 0
2. ($a = $b) * 3
3. ($a < $b) * 2
Which one should we stay with? $a or $b?
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 5:13 ` Felipe Contreras
@ 2021-05-12 6:47 ` Michal Suchánek
2021-05-12 9:06 ` Felipe Contreras
2021-05-12 16:47 ` Varun Varada
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-05-12 6:47 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, git
On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:
> Michal Suchánek wrote:
> > On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:
> > > It is a paradox called "the bikeshedding effect". When you contribute a
> > > complex and convoluted change it's easier to get it in because few people
> > > can object (as few people can understand it). But when you contribute a
> > > change as simple as changing the color of something, then *everyone* can
> > > opine (literally).
> >
> > You forget that what you are doing right now is bikeshedding after the
> > fact.
>
> Except that's not what I'm doing.
>
> > You can use 'affect' or 'impact' and it generally conveys the same
> > meaning.
>
> That's clearly *your* opinion, but that's not my opinon.
>
> I'm not arguing between blue and red; I'm arguing between water-based and
> lead-based paint.
No, you are not. There is no clear problem with 'impact', either.
So if somebody comes along later and says that they find 'affect'
confusing and impact should be used does that need to be accepted as
well, back and forth ad nauseam?
> The difference may not matter to you, but it matters to me.
>
> If it's bikeshedding to you, and it "gnerally conveys the same meaning",
> why are you arguing against?
So if 'for' loops and 'while' loops generally convey the same meaning
should we accept patches that replace some 'for' loops with 'while'
lopps or vice versa?
Surely not. There are different situations in which loops can be used,
and different people find 'for' and 'while' loops clearer and and easier
to understand in different situations. If you rewrite the piece of code
that includes a loop it might be worthwhile to change the loop type for
clarity, and at the time when the code is added or modified it is time
to discuss which one is better, not after.
On the other hand if you state the goal to not have redundant semicolons
then even if code with and without redundant semicolons is the same and
in most cases it does not make any difference for human understanding
either patches that just remove redundant semicolons work towards a
specific goal. That makes them acceptable even if they are very minor
because there is clear metric they improve which makes the inverse patch
not acceptable.
If you want to make the case for 'impact' in general being obscure or
hard to understand you will have hard time doing so. There are
dictionaries that recognize 'impact' as synonymous to 'affect' without
any difference in degree. In the COCA corpus there is around 200k
instances of 'effect', around 100k instances of 'affect', and around
100k instances of 'impact' which makes effect/affect about 3 times more
frequent than 'impact'. That's not even an order of magnitude - clearly
not enough to claim it obscure. All of the words are within first 1k so
arguably if you have intermediate knowledge of (US) English you should
be familiar with all three.
However, there is a different corpus that is much more relevant for the
git project:
✔ ~/git [master|…9]
06:35 $ git grep affect | wc -l
368
✔ ~/git [master|…9]
06:41 $ git grep effect | wc -l
350
✔ ~/git [master|…9]
06:42 $ git grep impact | wc -l
54
There are only 54 instances of the word 'impact' in the git repository
which make up only 7.5%. It is feasible to eliminate those 54 instances
completely. In doing so you will make the git project use the same
wording consistently which makes it arguably more approachable to
non-native speakers with limited vocabulary. That states a clear metric
that is improved by such patch which also makes the reverse patch not
acceptable and prevents potential for infinite back-and-forth changing
from one synonym to the other.
Bonus points if you add a test that prevents adding new instances of
'impact' in the future.
Thanks
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 6:47 ` Michal Suchánek
@ 2021-05-12 9:06 ` Felipe Contreras
2021-05-12 10:08 ` Michal Suchánek
2021-05-12 16:47 ` Varun Varada
1 sibling, 1 reply; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 9:06 UTC (permalink / raw)
To: Michal Suchánek, Felipe Contreras; +Cc: Varun Varada, git
Michal Suchánek wrote:
> On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:
> > Michal Suchánek wrote:
> > > You can use 'affect' or 'impact' and it generally conveys the same
> > > meaning.
> >
> > That's clearly *your* opinion, but that's not my opinon.
> >
> > I'm not arguing between blue and red; I'm arguing between water-based and
> > lead-based paint.
>
> No, you are not. There is no clear problem with 'impact', either.
There's no clear problem *to you*.
> So if somebody comes along later and says that they find 'affect'
> confusing and impact should be used does that need to be accepted as
> well, back and forth ad nauseam?
No. When that happens we start a new discussion, and see where that
leads.
> > The difference may not matter to you, but it matters to me.
> >
> > If it's bikeshedding to you, and it "gnerally conveys the same meaning",
> > why are you arguing against?
>
> So if 'for' loops and 'while' loops generally convey the same meaning
> should we accept patches that replace some 'for' loops with 'while'
> lopps or vice versa?
You are not answering my question, and you are providing an irrelevant
example.
I don't see any general difference between 'for' loops and 'while'
loops. But I do see a difference between 'impact' and 'affect'.
You are starting from the premise that $a is no different than $b.
That's your opinion, and I'm not disregarding it. But other people (e.g.
Varun and me) do have a different opinion.
Again, to make it crystal clear; you opine that $a and $b are equal, we
opine that they are not. We don't disregard your opinion, you do
disregard ours.
I don't know how much clearer I can make this.
> In the COCA corpus there is around 200k instances of 'effect', around
> 100k instances of 'affect', and around 100k instances of 'impact'
> which makes effect/affect about 3 times more frequent than 'impact'.
> That's not even an order of magnitude - clearly not enough to claim it
> obscure.
I don't think you understand the point.
The word "impact" is not obscure by any means.
The Chicxulub impactor (probably an asteroid) did create an impact on
Earth that probably killed all the non-avian dinosaurs. In that context
the word "impact" is 100% valid.
And you can find many such valid instances in those 100k COCA corpus
instances...
But not all.
The way the word "impact" is used in the git documentation is different
than the COCA corpus. Not all the instances of the word "impact" in the
git documentation refer to an event so drastic that it destroyed
thousands of species.
The point is very simple; there's valid ways of using the word "impact",
and there's invalid ways of using it. The git documentation for the most
part uses the word "impact" in an invalid way.
How many times the COCA corpuses uses "impact" in $b manner is
irrelevant to the number of times the git documentation uses the same
word in $a manner; the same word can have completely (and sometimes
opposite meanings).
The word "literally" sometimes means the exact opposite of the word
"literally". So if you find 1 million instances of the word "instance"
used in some way, that doesn't matter, because you might be using it in
a different way.
So... Can you answer my question?
Do you have anything against the word "affect" in *any* instance?
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 9:06 ` Felipe Contreras
@ 2021-05-12 10:08 ` Michal Suchánek
2021-05-12 10:33 ` Michal Suchánek
2021-05-12 11:05 ` Felipe Contreras
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-05-12 10:08 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, git
On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:
> Michal Suchánek wrote:
> > On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:
> > > Michal Suchánek wrote:
>
> > > > You can use 'affect' or 'impact' and it generally conveys the same
> > > > meaning.
> > >
> > > That's clearly *your* opinion, but that's not my opinon.
> > >
> > > I'm not arguing between blue and red; I'm arguing between water-based and
> > > lead-based paint.
> >
> > No, you are not. There is no clear problem with 'impact', either.
>
> There's no clear problem *to you*.
>
> > So if somebody comes along later and says that they find 'affect'
> > confusing and impact should be used does that need to be accepted as
> > well, back and forth ad nauseam?
>
> No. When that happens we start a new discussion, and see where that
> leads.
>
> > > The difference may not matter to you, but it matters to me.
> > >
> > > If it's bikeshedding to you, and it "gnerally conveys the same meaning",
> > > why are you arguing against?
> >
> > So if 'for' loops and 'while' loops generally convey the same meaning
> > should we accept patches that replace some 'for' loops with 'while'
> > lopps or vice versa?
>
> You are not answering my question, and you are providing an irrelevant
> example.
>
> I don't see any general difference between 'for' loops and 'while'
> loops. But I do see a difference between 'impact' and 'affect'.
>
> You are starting from the premise that $a is no different than $b.
> That's your opinion, and I'm not disregarding it. But other people (e.g.
> Varun and me) do have a different opinion.
>
> Again, to make it crystal clear; you opine that $a and $b are equal, we
> opine that they are not. We don't disregard your opinion, you do
> disregard ours.
>
> I don't know how much clearer I can make this.
>
> > In the COCA corpus there is around 200k instances of 'effect', around
> > 100k instances of 'affect', and around 100k instances of 'impact'
> > which makes effect/affect about 3 times more frequent than 'impact'.
> > That's not even an order of magnitude - clearly not enough to claim it
> > obscure.
>
> I don't think you understand the point.
>
> The word "impact" is not obscure by any means.
>
> The Chicxulub impactor (probably an asteroid) did create an impact on
> Earth that probably killed all the non-avian dinosaurs. In that context
> the word "impact" is 100% valid.
>
> And you can find many such valid instances in those 100k COCA corpus
> instances...
>
> But not all.
>
>
> The way the word "impact" is used in the git documentation is different
> than the COCA corpus. Not all the instances of the word "impact" in the
> git documentation refer to an event so drastic that it destroyed
> thousands of species.
>
> The point is very simple; there's valid ways of using the word "impact",
> and there's invalid ways of using it. The git documentation for the most
> part uses the word "impact" in an invalid way.
>
> How many times the COCA corpuses uses "impact" in $b manner is
> irrelevant to the number of times the git documentation uses the same
> word in $a manner; the same word can have completely (and sometimes
> opposite meanings).
>
> The word "literally" sometimes means the exact opposite of the word
> "literally". So if you find 1 million instances of the word "instance"
> used in some way, that doesn't matter, because you might be using it in
> a different way.
>
>
> So... Can you answer my question?
>
> Do you have anything against the word "affect" in *any* instance?
Yss, the Merriam-Webster dictionary also lists the meaning
"to cause illness, symptoms, etc." I don't think something that drastic
should be included in the git documentation.
SCNR
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 10:08 ` Michal Suchánek
@ 2021-05-12 10:33 ` Michal Suchánek
2021-05-12 11:05 ` Felipe Contreras
1 sibling, 0 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-05-12 10:33 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, git
On Wed, May 12, 2021 at 12:08:55PM +0200, Michal Suchánek wrote:
> On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:
> > Michal Suchánek wrote:
> > > On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:
> > > > Michal Suchánek wrote:
> >
> > > > > You can use 'affect' or 'impact' and it generally conveys the same
> > > > > meaning.
> > > >
> > > > That's clearly *your* opinion, but that's not my opinon.
> > > >
> > > > I'm not arguing between blue and red; I'm arguing between water-based and
> > > > lead-based paint.
> > >
> > > No, you are not. There is no clear problem with 'impact', either.
> >
> > There's no clear problem *to you*.
> >
> > > So if somebody comes along later and says that they find 'affect'
> > > confusing and impact should be used does that need to be accepted as
> > > well, back and forth ad nauseam?
> >
> > No. When that happens we start a new discussion, and see where that
> > leads.
> >
> > > > The difference may not matter to you, but it matters to me.
> > > >
> > > > If it's bikeshedding to you, and it "gnerally conveys the same meaning",
> > > > why are you arguing against?
> > >
> > > So if 'for' loops and 'while' loops generally convey the same meaning
> > > should we accept patches that replace some 'for' loops with 'while'
> > > lopps or vice versa?
> >
> > You are not answering my question, and you are providing an irrelevant
> > example.
> >
> > I don't see any general difference between 'for' loops and 'while'
> > loops. But I do see a difference between 'impact' and 'affect'.
> >
> > You are starting from the premise that $a is no different than $b.
> > That's your opinion, and I'm not disregarding it. But other people (e.g.
> > Varun and me) do have a different opinion.
> >
> > Again, to make it crystal clear; you opine that $a and $b are equal, we
> > opine that they are not. We don't disregard your opinion, you do
> > disregard ours.
> >
> > I don't know how much clearer I can make this.
And changes to git should be based on fact, not opinion.
I don't know how much clearer I can state it.
Thanks
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 10:08 ` Michal Suchánek
2021-05-12 10:33 ` Michal Suchánek
@ 2021-05-12 11:05 ` Felipe Contreras
2021-05-12 11:20 ` Michal Suchánek
1 sibling, 1 reply; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 11:05 UTC (permalink / raw)
To: Michal Suchánek, Felipe Contreras; +Cc: Varun Varada, git
Michal Suchánek wrote:
> On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:
> > So... Can you answer my question?
> >
> > Do you have anything against the word "affect" in *any* instance?
>
> Yss, the Merriam-Webster dictionary also lists the meaning
> "to cause illness, symptoms, etc."
I did not ask you if you could list one definition contrary to the
intended purpose of the word "affect".
I asked you if you have something againt the word "affect".
We can use your same logic to find one definition for the word "impact"
contrary to your intended purpose.
That's not the intention of the question.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 11:05 ` Felipe Contreras
@ 2021-05-12 11:20 ` Michal Suchánek
2021-05-12 11:45 ` Robert P. J. Day
0 siblings, 1 reply; 68+ messages in thread
From: Michal Suchánek @ 2021-05-12 11:20 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, git
On Wed, May 12, 2021 at 06:05:32AM -0500, Felipe Contreras wrote:
> Michal Suchánek wrote:
> > On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:
> > > So... Can you answer my question?
> > >
> > > Do you have anything against the word "affect" in *any* instance?
> >
> > Yss, the Merriam-Webster dictionary also lists the meaning
> > "to cause illness, symptoms, etc."
>
> I did not ask you if you could list one definition contrary to the
> intended purpose of the word "affect".
>
> I asked you if you have something againt the word "affect".
>
> We can use your same logic to find one definition for the word "impact"
> contrary to your intended purpose.
That's exactly the point you have been making, though.
>
> That's not the intention of the question.
>
> --
> Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 11:20 ` Michal Suchánek
@ 2021-05-12 11:45 ` Robert P. J. Day
2021-05-12 15:19 ` Kerry, Richard
0 siblings, 1 reply; 68+ messages in thread
From: Robert P. J. Day @ 2021-05-12 11:45 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Felipe Contreras, Varun Varada, git
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
On Wed, 12 May 2021, Michal Suchánek wrote:
> On Wed, May 12, 2021 at 06:05:32AM -0500, Felipe Contreras wrote:
> > Michal Suchánek wrote:
> > > On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:
> > > > So... Can you answer my question?
> > > >
> > > > Do you have anything against the word "affect" in *any* instance?
> > >
> > > Yss, the Merriam-Webster dictionary also lists the meaning
> > > "to cause illness, symptoms, etc."
> >
> > I did not ask you if you could list one definition contrary to the
> > intended purpose of the word "affect".
> >
> > I asked you if you have something againt the word "affect".
> >
> > We can use your same logic to find one definition for the word "impact"
> > contrary to your intended purpose.
>
> That's exactly the point you have been making, though.
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?
rday
^ permalink raw reply [flat|nested] 68+ messages in thread
* RE: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 11:45 ` Robert P. J. Day
@ 2021-05-12 15:19 ` Kerry, Richard
0 siblings, 0 replies; 68+ messages in thread
From: Kerry, Richard @ 2021-05-12 15:19 UTC (permalink / raw)
To: git
Speaking as a native (British) English speaker I don't have the slightest problem with the word "impact" being used in this context.
Remember English is not one of those languages with an Academy or committee that defines what is correct.
It 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.
Regards,
Richard.
Ps. Sorry about top-posting. Not sure if I can get Outlook to do a nice set-up for anything else.
-----Original Message-----
From: Robert P. J. Day <rpjday@crashcourse.ca>
Sent: 12 May 2021 12:45
To: Michal Suchánek <msuchanek@suse.de>
Cc: Felipe Contreras <felipe.contreras@gmail.com>; Varun Varada <varuncvarada@gmail.com>; git@vger.kernel.org
Subject: Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.
On Wed, 12 May 2021, Michal Suchánek wrote:
> On Wed, May 12, 2021 at 06:05:32AM -0500, Felipe Contreras wrote:
> > Michal Suchánek wrote:
> > > On Wed, May 12, 2021 at 04:06:56AM -0500, Felipe Contreras wrote:
> > > > So... Can you answer my question?
> > > >
> > > > Do you have anything against the word "affect" in *any* instance?
> > >
> > > Yss, the Merriam-Webster dictionary also lists the meaning "to
> > > cause illness, symptoms, etc."
> >
> > I did not ask you if you could list one definition contrary to the
> > intended purpose of the word "affect".
> >
> > I asked you if you have something againt the word "affect".
> >
> > We can use your same logic to find one definition for the word "impact"
> > contrary to your intended purpose.
>
> That's exactly the point you have been making, though.
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?
rday
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 4:11 ` Michal Suchánek
2021-05-12 5:22 ` Felipe Contreras
@ 2021-05-12 16:39 ` Varun Varada
1 sibling, 0 replies; 68+ messages in thread
From: Varun Varada @ 2021-05-12 16:39 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Felipe Contreras, git
On Tue, 11 May 2021 at 23:11, Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Tue, May 11, 2021 at 10:09:56PM -0500, Felipe Contreras wrote:
> > Michal Suchánek wrote:
> > > On Tue, May 11, 2021 at 02:21:43PM -0500, Felipe Contreras wrote:
> > > > Michal Suchánek wrote:
> >
> > > > > If you are concerned about correctness and clarity of the documentation please
> > > > > avoid spreading misinformation.
> > > >
> > > > Under certain definition of "jaron" Varun's statement would be
> > > > incorrect, but not under all definitions. If you use the definition
> > > > I stated above, "impact" can be considered jargon, because it's a bit
> > > > obscure language.
> > >
> > > Do you have any frequency data that supports your claim that the word
> > > 'impact' is obscure?
> >
> > This is not how logic works.
> >
> > If I don't have frequency data that supports $x, but you have no
> > frequency data that supports !$x, then we return to the default position;
> > we don't know if $x is true or not.
> >
> > Do **you** have any frequency data that supports the negative claim that
> > the word "impact" is not obscure?
>
> I don't need that data. You are proposing a change so it is your duty to
> support your claim that the change is worthwhile.
> Otherwise it's a change just for the sake of change.
>
> >
> > > The bar for change should be that the word as used is very unfitting or
> > > unintelligible.
> >
> > No. The bar is that **nobody** have any problem with "affect", and some
> > people have a problem with "impact".
>
> And that's established how, specifically?
By way of dictionaries and style guides which universally agree on the
meaning of "affect"/"effect", but do not on that of (and even
explicitly discourage) "impact".
>
> Thanks
>
> Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 6:47 ` Michal Suchánek
2021-05-12 9:06 ` Felipe Contreras
@ 2021-05-12 16:47 ` Varun Varada
2021-05-12 17:01 ` Michal Suchánek
1 sibling, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-05-12 16:47 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Felipe Contreras, git
On Wed, 12 May 2021 at 01:47, Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:
> > Michal Suchánek wrote:
> > > On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:
> > > > It is a paradox called "the bikeshedding effect". When you contribute a
> > > > complex and convoluted change it's easier to get it in because few people
> > > > can object (as few people can understand it). But when you contribute a
> > > > change as simple as changing the color of something, then *everyone* can
> > > > opine (literally).
> > >
> > > You forget that what you are doing right now is bikeshedding after the
> > > fact.
> >
> > Except that's not what I'm doing.
> >
> > > You can use 'affect' or 'impact' and it generally conveys the same
> > > meaning.
> >
> > That's clearly *your* opinion, but that's not my opinon.
> >
> > I'm not arguing between blue and red; I'm arguing between water-based and
> > lead-based paint.
>
> No, you are not. There is no clear problem with 'impact', either.
>
> So if somebody comes along later and says that they find 'affect'
> confusing and impact should be used does that need to be accepted as
> well, back and forth ad nauseam?
This is whataboutism and hypothetical. But even if one were to
disregard those facts, I'm willing to bet actual money that no one (at
least anyone with access to a dictionary or even a basic grasp of the
English language) would do this because "affect" has a universal
definition and is not in the realm of jargon in any dictionary or
style guide. The same cannot be said about "impact".
>
> > The difference may not matter to you, but it matters to me.
> >
> > If it's bikeshedding to you, and it "gnerally conveys the same meaning",
> > why are you arguing against?
>
> So if 'for' loops and 'while' loops generally convey the same meaning
> should we accept patches that replace some 'for' loops with 'while'
> lopps or vice versa?
>
> Surely not. There are different situations in which loops can be used,
> and different people find 'for' and 'while' loops clearer and and easier
> to understand in different situations. If you rewrite the piece of code
> that includes a loop it might be worthwhile to change the loop type for
> clarity, and at the time when the code is added or modified it is time
> to discuss which one is better, not after.
>
> On the other hand if you state the goal to not have redundant semicolons
> then even if code with and without redundant semicolons is the same and
> in most cases it does not make any difference for human understanding
> either patches that just remove redundant semicolons work towards a
> specific goal. That makes them acceptable even if they are very minor
> because there is clear metric they improve which makes the inverse patch
> not acceptable.
>
> If you want to make the case for 'impact' in general being obscure or
> hard to understand you will have hard time doing so. There are
> dictionaries that recognize 'impact' as synonymous to 'affect' without
> any difference in degree. In the COCA corpus there is around 200k
> instances of 'effect', around 100k instances of 'affect', and around
> 100k instances of 'impact' which makes effect/affect about 3 times more
> frequent than 'impact'. That's not even an order of magnitude - clearly
> not enough to claim it obscure. All of the words are within first 1k so
> arguably if you have intermediate knowledge of (US) English you should
> be familiar with all three.
>
> However, there is a different corpus that is much more relevant for the
> git project:
>
> ✔ ~/git [master|…9]
> 06:35 $ git grep affect | wc -l
> 368
> ✔ ~/git [master|…9]
> 06:41 $ git grep effect | wc -l
> 350
> ✔ ~/git [master|…9]
> 06:42 $ git grep impact | wc -l
> 54
>
> There are only 54 instances of the word 'impact' in the git repository
> which make up only 7.5%. It is feasible to eliminate those 54 instances
> completely. In doing so you will make the git project use the same
> wording consistently which makes it arguably more approachable to
> non-native speakers with limited vocabulary. That states a clear metric
> that is improved by such patch which also makes the reverse patch not
> acceptable and prevents potential for infinite back-and-forth changing
> from one synonym to the other.
>
> Bonus points if you add a test that prevents adding new instances of
> 'impact' in the future.
So you're saying you're OK with getting rid of all instances of
"impact"? I'm for this, but insofar as I searched the code base, I
only found the ones I'm changing in my patch (save for a couple that,
as a previous reviewer mentioned, are included from other repos, so I
left those).
>
> Thanks
>
> Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 16:47 ` Varun Varada
@ 2021-05-12 17:01 ` Michal Suchánek
2021-05-12 17:32 ` Felipe Contreras
2021-05-12 22:52 ` Varun Varada
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-05-12 17:01 UTC (permalink / raw)
To: Varun Varada; +Cc: Felipe Contreras, git
On Wed, May 12, 2021 at 11:47:15AM -0500, Varun Varada wrote:
> On Wed, 12 May 2021 at 01:47, Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:
> > > Michal Suchánek wrote:
> > > > On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:
> > > > > It is a paradox called "the bikeshedding effect". When you contribute a
> > > > > complex and convoluted change it's easier to get it in because few people
> > > > > can object (as few people can understand it). But when you contribute a
> > > > > change as simple as changing the color of something, then *everyone* can
> > > > > opine (literally).
> > > >
> > > > You forget that what you are doing right now is bikeshedding after the
> > > > fact.
> > >
> > > Except that's not what I'm doing.
> > >
> > > > You can use 'affect' or 'impact' and it generally conveys the same
> > > > meaning.
> > >
> > > That's clearly *your* opinion, but that's not my opinon.
> > >
> > > I'm not arguing between blue and red; I'm arguing between water-based and
> > > lead-based paint.
> >
> > No, you are not. There is no clear problem with 'impact', either.
> >
> > So if somebody comes along later and says that they find 'affect'
> > confusing and impact should be used does that need to be accepted as
> > well, back and forth ad nauseam?
>
> This is whataboutism and hypothetical. But even if one were to
> disregard those facts, I'm willing to bet actual money that no one (at
> least anyone with access to a dictionary or even a basic grasp of the
> English language) would do this because "affect" has a universal
> definition and is not in the realm of jargon in any dictionary or
> style guide. The same cannot be said about "impact".
>
> >
> > > The difference may not matter to you, but it matters to me.
> > >
> > > If it's bikeshedding to you, and it "gnerally conveys the same meaning",
> > > why are you arguing against?
> >
> > So if 'for' loops and 'while' loops generally convey the same meaning
> > should we accept patches that replace some 'for' loops with 'while'
> > lopps or vice versa?
> >
> > Surely not. There are different situations in which loops can be used,
> > and different people find 'for' and 'while' loops clearer and and easier
> > to understand in different situations. If you rewrite the piece of code
> > that includes a loop it might be worthwhile to change the loop type for
> > clarity, and at the time when the code is added or modified it is time
> > to discuss which one is better, not after.
> >
> > On the other hand if you state the goal to not have redundant semicolons
> > then even if code with and without redundant semicolons is the same and
> > in most cases it does not make any difference for human understanding
> > either patches that just remove redundant semicolons work towards a
> > specific goal. That makes them acceptable even if they are very minor
> > because there is clear metric they improve which makes the inverse patch
> > not acceptable.
> >
> > If you want to make the case for 'impact' in general being obscure or
> > hard to understand you will have hard time doing so. There are
> > dictionaries that recognize 'impact' as synonymous to 'affect' without
> > any difference in degree. In the COCA corpus there is around 200k
> > instances of 'effect', around 100k instances of 'affect', and around
> > 100k instances of 'impact' which makes effect/affect about 3 times more
> > frequent than 'impact'. That's not even an order of magnitude - clearly
> > not enough to claim it obscure. All of the words are within first 1k so
> > arguably if you have intermediate knowledge of (US) English you should
> > be familiar with all three.
> >
> > However, there is a different corpus that is much more relevant for the
> > git project:
> >
> > ✔ ~/git [master|…9]
> > 06:35 $ git grep affect | wc -l
> > 368
> > ✔ ~/git [master|…9]
> > 06:41 $ git grep effect | wc -l
> > 350
> > ✔ ~/git [master|…9]
> > 06:42 $ git grep impact | wc -l
> > 54
> >
> > There are only 54 instances of the word 'impact' in the git repository
> > which make up only 7.5%. It is feasible to eliminate those 54 instances
> > completely. In doing so you will make the git project use the same
> > wording consistently which makes it arguably more approachable to
> > non-native speakers with limited vocabulary. That states a clear metric
> > that is improved by such patch which also makes the reverse patch not
> > acceptable and prevents potential for infinite back-and-forth changing
> > from one synonym to the other.
> >
> > Bonus points if you add a test that prevents adding new instances of
> > 'impact' in the future.
>
> So you're saying you're OK with getting rid of all instances of
> "impact"? I'm for this, but insofar as I searched the code base, I
> only found the ones I'm changing in my patch (save for a couple that,
> as a previous reviewer mentioned, are included from other repos, so I
> left those).
Yes, I am not opposed to the change in principle. You just failed to
provide any valid reason.
Part of writing a patch is coming up with sound reasoning why the change
is desirable and stating that clearly in the commit message.
I don't know if this reasoning is acceptable to git maintainers but at
least there is some real data it is based on.
Thanks
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 17:01 ` Michal Suchánek
@ 2021-05-12 17:32 ` Felipe Contreras
2021-05-12 18:04 ` Michal Suchánek
2021-05-12 22:52 ` Varun Varada
1 sibling, 1 reply; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 17:32 UTC (permalink / raw)
To: Michal Suchánek, Varun Varada; +Cc: Felipe Contreras, git
Michal Suchánek wrote:
> On Wed, May 12, 2021 at 11:47:15AM -0500, Varun Varada wrote:
> > So you're saying you're OK with getting rid of all instances of
> > "impact"? I'm for this, but insofar as I searched the code base, I
> > only found the ones I'm changing in my patch (save for a couple that,
> > as a previous reviewer mentioned, are included from other repos, so I
> > left those).
>
> Yes, I am not opposed to the change in principle.
Good, so you accept you see nothing wrong with "affect".
> You just failed to provide any valid reason.
*In your opinion*.
In my opinion the problems with the word "impact" have been clearly
explained.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 17:32 ` Felipe Contreras
@ 2021-05-12 18:04 ` Michal Suchánek
2021-05-12 19:42 ` Felipe Contreras
0 siblings, 1 reply; 68+ messages in thread
From: Michal Suchánek @ 2021-05-12 18:04 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, git
On Wed, May 12, 2021 at 12:32:16PM -0500, Felipe Contreras wrote:
> Michal Suchánek wrote:
> > On Wed, May 12, 2021 at 11:47:15AM -0500, Varun Varada wrote:
> > > So you're saying you're OK with getting rid of all instances of
> > > "impact"? I'm for this, but insofar as I searched the code base, I
> > > only found the ones I'm changing in my patch (save for a couple that,
> > > as a previous reviewer mentioned, are included from other repos, so I
> > > left those).
> >
> > Yes, I am not opposed to the change in principle.
>
> Good, so you accept you see nothing wrong with "affect".
>
> > You just failed to provide any valid reason.
>
> *In your opinion*.
>
> In my opinion the problems with the word "impact" have been clearly
> explained.
However, you only brought your personal opinion for the case that
'impact' is somehow wrong and should be changed. 'impact' and 'affect'
are equally good based on the past discussion so you will not bring
change based on the 'badness' of 'impact'.
You claim that people who do not want to change 'impact' ignore your
opinion.
Don't you equally ignore the opinion of people who think 'impact' is
fine by insisting that the wording be changed based solely on your
opinion?
Cheers
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 18:04 ` Michal Suchánek
@ 2021-05-12 19:42 ` Felipe Contreras
2021-05-13 7:46 ` Michal Suchánek
0 siblings, 1 reply; 68+ messages in thread
From: Felipe Contreras @ 2021-05-12 19:42 UTC (permalink / raw)
To: Michal Suchánek, Felipe Contreras; +Cc: Varun Varada, git
Michal Suchánek wrote:
> On Wed, May 12, 2021 at 12:32:16PM -0500, Felipe Contreras wrote:
> > Michal Suchánek wrote:
> > > Yes, I am not opposed to the change in principle.
> >
> > Good, so you accept you see nothing wrong with "affect".
> >
> > > You just failed to provide any valid reason.
> >
> > *In your opinion*.
> >
> > In my opinion the problems with the word "impact" have been clearly
> > explained.
>
> However, you only brought your personal opinion for the case that
> 'impact' is somehow wrong and should be changed.
No I didn't. I used dictionary definitions to explain why it's wrong to
use it the way git uses both as a noun and a transitive verb.
> 'impact' and 'affect' are equally good based on the past discussion so
> you will not bring change based on the 'badness' of 'impact'.
That is your opinion, and its not shared by everyone.
It's extremely disingenious to elevate your opinion as fact, especially
when this is precisely the thing we are discussing.
> You claim that people who do not want to change 'impact' ignore your
> opinion.
No I don't.
I clam *you* pretend other opinions don't even exist.
> Don't you equally ignore the opinion of people who think 'impact' is
> fine by insisting that the wording be changed based solely on your
> opinion?
No, unlike you I acknowledge there's other people with different
opinions.
However, that opinion is that "impact" is fine, *not* that "affect" is
bad.
If you and your wife are deciding what to eat for dinner, and you have
two opinions:
1. Whatever is fine
2. I really would like pizza
What do you think you should order?
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 17:01 ` Michal Suchánek
2021-05-12 17:32 ` Felipe Contreras
@ 2021-05-12 22:52 ` Varun Varada
2021-05-13 6:19 ` Felipe Contreras
1 sibling, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-05-12 22:52 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Felipe Contreras, git
On Wed, 12 May 2021 at 12:01, Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Wed, May 12, 2021 at 11:47:15AM -0500, Varun Varada wrote:
> > On Wed, 12 May 2021 at 01:47, Michal Suchánek <msuchanek@suse.de> wrote:
> > >
> > > On Wed, May 12, 2021 at 12:13:08AM -0500, Felipe Contreras wrote:
> > > > Michal Suchánek wrote:
> > > > > On Tue, May 11, 2021 at 10:43:38PM -0500, Felipe Contreras wrote:
> > > > > > It is a paradox called "the bikeshedding effect". When you contribute a
> > > > > > complex and convoluted change it's easier to get it in because few people
> > > > > > can object (as few people can understand it). But when you contribute a
> > > > > > change as simple as changing the color of something, then *everyone* can
> > > > > > opine (literally).
> > > > >
> > > > > You forget that what you are doing right now is bikeshedding after the
> > > > > fact.
> > > >
> > > > Except that's not what I'm doing.
> > > >
> > > > > You can use 'affect' or 'impact' and it generally conveys the same
> > > > > meaning.
> > > >
> > > > That's clearly *your* opinion, but that's not my opinon.
> > > >
> > > > I'm not arguing between blue and red; I'm arguing between water-based and
> > > > lead-based paint.
> > >
> > > No, you are not. There is no clear problem with 'impact', either.
> > >
> > > So if somebody comes along later and says that they find 'affect'
> > > confusing and impact should be used does that need to be accepted as
> > > well, back and forth ad nauseam?
> >
> > This is whataboutism and hypothetical. But even if one were to
> > disregard those facts, I'm willing to bet actual money that no one (at
> > least anyone with access to a dictionary or even a basic grasp of the
> > English language) would do this because "affect" has a universal
> > definition and is not in the realm of jargon in any dictionary or
> > style guide. The same cannot be said about "impact".
> >
> > >
> > > > The difference may not matter to you, but it matters to me.
> > > >
> > > > If it's bikeshedding to you, and it "gnerally conveys the same meaning",
> > > > why are you arguing against?
> > >
> > > So if 'for' loops and 'while' loops generally convey the same meaning
> > > should we accept patches that replace some 'for' loops with 'while'
> > > lopps or vice versa?
> > >
> > > Surely not. There are different situations in which loops can be used,
> > > and different people find 'for' and 'while' loops clearer and and easier
> > > to understand in different situations. If you rewrite the piece of code
> > > that includes a loop it might be worthwhile to change the loop type for
> > > clarity, and at the time when the code is added or modified it is time
> > > to discuss which one is better, not after.
> > >
> > > On the other hand if you state the goal to not have redundant semicolons
> > > then even if code with and without redundant semicolons is the same and
> > > in most cases it does not make any difference for human understanding
> > > either patches that just remove redundant semicolons work towards a
> > > specific goal. That makes them acceptable even if they are very minor
> > > because there is clear metric they improve which makes the inverse patch
> > > not acceptable.
> > >
> > > If you want to make the case for 'impact' in general being obscure or
> > > hard to understand you will have hard time doing so. There are
> > > dictionaries that recognize 'impact' as synonymous to 'affect' without
> > > any difference in degree. In the COCA corpus there is around 200k
> > > instances of 'effect', around 100k instances of 'affect', and around
> > > 100k instances of 'impact' which makes effect/affect about 3 times more
> > > frequent than 'impact'. That's not even an order of magnitude - clearly
> > > not enough to claim it obscure. All of the words are within first 1k so
> > > arguably if you have intermediate knowledge of (US) English you should
> > > be familiar with all three.
> > >
> > > However, there is a different corpus that is much more relevant for the
> > > git project:
> > >
> > > ✔ ~/git [master|…9]
> > > 06:35 $ git grep affect | wc -l
> > > 368
> > > ✔ ~/git [master|…9]
> > > 06:41 $ git grep effect | wc -l
> > > 350
> > > ✔ ~/git [master|…9]
> > > 06:42 $ git grep impact | wc -l
> > > 54
> > >
> > > There are only 54 instances of the word 'impact' in the git repository
> > > which make up only 7.5%. It is feasible to eliminate those 54 instances
> > > completely. In doing so you will make the git project use the same
> > > wording consistently which makes it arguably more approachable to
> > > non-native speakers with limited vocabulary. That states a clear metric
> > > that is improved by such patch which also makes the reverse patch not
> > > acceptable and prevents potential for infinite back-and-forth changing
> > > from one synonym to the other.
> > >
> > > Bonus points if you add a test that prevents adding new instances of
> > > 'impact' in the future.
> >
> > So you're saying you're OK with getting rid of all instances of
> > "impact"? I'm for this, but insofar as I searched the code base, I
> > only found the ones I'm changing in my patch (save for a couple that,
> > as a previous reviewer mentioned, are included from other repos, so I
> > left those).
>
> Yes, I am not opposed to the change in principle. You just failed to
> provide any valid reason.
>
> Part of writing a patch is coming up with sound reasoning why the change
> is desirable and stating that clearly in the commit message.
>
> I don't know if this reasoning is acceptable to git maintainers but at
> least there is some real data it is based on.
It's useful to think of this commit via these perspectives:
1. Do you think "affect" and "impact" are synonymous? Fine; this
change doesn't affect (no pun intended) you.
2. Do you think "impact" is incorrectly used here? Great, because
that's what the commit is for.
3. Do you think neither of the above are relevant, but want to get rid
of the word "impact" completely from the Git repository specifically
because of its relatively seldom use? That's great as well, since this
commit conveniently also addresses all instances of the word within
the code base that are stable/controlled by the Git repo (i.e., not
directly imported from other code bases).
The advantage, fortunately, is that you can like any or all of these
reasons, and we don't have to agree on which ones are the most
important or relevant. The end result is the same: a less ambiguous
code base that makes everyone happy.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 22:52 ` Varun Varada
@ 2021-05-13 6:19 ` Felipe Contreras
0 siblings, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-13 6:19 UTC (permalink / raw)
To: Varun Varada, Michal Suchánek; +Cc: Felipe Contreras, git
Varun Varada wrote:
> The advantage, fortunately, is that you can like any or all of these
> reasons, and we don't have to agree on which ones are the most
> important or relevant. The end result is the same: a less ambiguous
> code base that makes everyone happy.
Or rather: doesn't make anyone unhappy.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-12 19:42 ` Felipe Contreras
@ 2021-05-13 7:46 ` Michal Suchánek
2021-05-13 8:28 ` Felipe Contreras
2021-05-13 8:55 ` Robert Coup
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-05-13 7:46 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, git
On Wed, May 12, 2021 at 02:42:16PM -0500, Felipe Contreras wrote:
> Michal Suchánek wrote:
> > On Wed, May 12, 2021 at 12:32:16PM -0500, Felipe Contreras wrote:
> > > Michal Suchánek wrote:
> > > > Yes, I am not opposed to the change in principle.
> > >
> > > Good, so you accept you see nothing wrong with "affect".
> > >
> > > > You just failed to provide any valid reason.
> > >
> > > *In your opinion*.
> > >
> > > In my opinion the problems with the word "impact" have been clearly
> > > explained.
> >
> > However, you only brought your personal opinion for the case that
> > 'impact' is somehow wrong and should be changed.
>
> No I didn't. I used dictionary definitions to explain why it's wrong to
> use it the way git uses both as a noun and a transitive verb.
>
> > 'impact' and 'affect' are equally good based on the past discussion so
> > you will not bring change based on the 'badness' of 'impact'.
>
> That is your opinion, and its not shared by everyone.
>
> It's extremely disingenious to elevate your opinion as fact, especially
> when this is precisely the thing we are discussing.
>
> > You claim that people who do not want to change 'impact' ignore your
> > opinion.
>
> No I don't.
>
> I clam *you* pretend other opinions don't even exist.
>
> > Don't you equally ignore the opinion of people who think 'impact' is
> > fine by insisting that the wording be changed based solely on your
> > opinion?
>
> No, unlike you I acknowledge there's other people with different
> opinions.
>
> However, that opinion is that "impact" is fine, *not* that "affect" is
> bad.
>
>
> If you and your wife are deciding what to eat for dinner, and you have
> two opinions:
>
> 1. Whatever is fine
> 2. I really would like pizza
>
> What do you think you should order?
That would be the situation if you comented on the patch adding 'impact'
before it was merged.
If you want a dining metaphor for the current situation it would be more
like
1. There are 100 people around the table eating lasagne
2. You stand up and say you don't like lasagne and pizza should be
brought instead
3. people say comeon, we already have lasagne. And are you so sure if we
bring in pizza instead that nobody will object?
4. you say nonsense, pizza is the best, nobody ever objected to it.
5. you start banging your cutlery against the plate and shouting to
bring the pizza already
Sounds very rude to me.
Best regards
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-13 7:46 ` Michal Suchánek
@ 2021-05-13 8:28 ` Felipe Contreras
2021-05-13 8:55 ` Robert Coup
1 sibling, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-13 8:28 UTC (permalink / raw)
To: Michal Suchánek, Felipe Contreras; +Cc: Varun Varada, git
Michal Suchánek wrote:
> On Wed, May 12, 2021 at 02:42:16PM -0500, Felipe Contreras wrote:
> > If you and your wife are deciding what to eat for dinner, and you have
> > two opinions:
> >
> > 1. Whatever is fine
> > 2. I really would like pizza
> >
> > What do you think you should order?
>
> That would be the situation if you comented on the patch adding 'impact'
> before it was merged.
No analogy is perfect.
> If you want a dining metaphor for the current situation it would be more
> like
>
> 1. There are 100 people around the table eating lasagne
You are starting wrong. *Nobody* is reading the word "impact" right now,
and we are not going to swap the word in the middle of their reading.
This is a much worse analogy, and I seriously doubt you actually think
this remotely resembles the situation at hand.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-13 7:46 ` Michal Suchánek
2021-05-13 8:28 ` Felipe Contreras
@ 2021-05-13 8:55 ` Robert Coup
2021-05-13 9:48 ` Michal Suchánek
1 sibling, 1 reply; 68+ messages in thread
From: Robert Coup @ 2021-05-13 8:55 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Felipe Contreras, Varun Varada, git
Hi Michal,
On Thu, 13 May 2021 at 08:47, Michal Suchánek <msuchanek@suse.de> wrote:
>
> That would be the situation if you comented on the patch adding 'impact'
> before it was merged.
As a lurker (and there are a lot more of us than people who email the
list), this comes across to me as veering well into bad faith. Because
it wasn't picked up at the time it can never be improved? Code doesn't
work that way, neither should any other aspect of the project.
Non-native English speakers outnumber native ones about 3:1 [1], and
even within native English speaking countries there are variances in
common vocabulary. This sort of stuff trips up non-native speakers
though (and the lack of rules in English makes it difficult enough) -
why would we want to make understanding Git harder for people when
there's a simple improvement to be had?
Rob :)
[1] https://en.wikipedia.org/wiki/English-speaking_world#cite_ref-Two_thousand_million_2-1
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-13 8:55 ` Robert Coup
@ 2021-05-13 9:48 ` Michal Suchánek
2021-05-13 9:59 ` Felipe Contreras
2021-05-26 23:49 ` Varun Varada
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-05-13 9:48 UTC (permalink / raw)
To: Robert Coup; +Cc: Felipe Contreras, Varun Varada, git
On Thu, May 13, 2021 at 09:55:42AM +0100, Robert Coup wrote:
> Hi Michal,
>
> On Thu, 13 May 2021 at 08:47, Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > That would be the situation if you comented on the patch adding 'impact'
> > before it was merged.
>
> As a lurker (and there are a lot more of us than people who email the
> list), this comes across to me as veering well into bad faith. Because
> it wasn't picked up at the time it can never be improved? Code doesn't
> work that way, neither should any other aspect of the project.
>
> Non-native English speakers outnumber native ones about 3:1 [1], and
> even within native English speaking countries there are variances in
> common vocabulary. This sort of stuff trips up non-native speakers
> though (and the lack of rules in English makes it difficult enough) -
> why would we want to make understanding Git harder for people when
> there's a simple improvement to be had?
Indeed, and I even provided an argument why eliminating 'impact' in git
would likely improve the situation for non-native speakers. 'impact' is
very rarely used in git, and by eliminating it (which is completely
feasible) we reduce the vocabulary needed to read git documentation and
make it more consistent.
Yet Felipe insists that 'impact' is somehow generally bad word to use or
that it should be abolished solely because he finds it bad and nobody
objected to the alternative wording.
Opinions on use of 'impact' differ both among the participants of this
discussion and authorities like authors well-known dictionaries.
It looks like this is generally matter of stylistic preferences and
opinions. That is even if there is some slight stylistic preference for
not using the word 'impact' it is very hard to prove such and then it is
very hard to request change based only on writing style preferences.
That's not to say it's impossible but Felipe chooses the option to
rehash the same arguments ad nauseam without bringing clear and
substantial arguments in favor of the change.
Thanks
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-13 9:48 ` Michal Suchánek
@ 2021-05-13 9:59 ` Felipe Contreras
2021-05-26 23:49 ` Varun Varada
1 sibling, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-13 9:59 UTC (permalink / raw)
To: Michal Suchánek, Robert Coup; +Cc: Felipe Contreras, Varun Varada, git
Michal Suchánek wrote:
> Yet Felipe insists that 'impact' is somehow generally bad word to use or
> that it should be abolished solely because he finds it bad and nobody
> objected to the alternative wording.
That is most certainly not what I said.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-04-05 21:48 [PATCH] doc: replace jargon word "impact" with "effect"/"affect" Varun Varada
2021-04-06 9:24 ` Michal Suchánek
@ 2021-05-13 10:40 ` Philip Oakley
2021-05-26 23:52 ` Varun Varada
1 sibling, 1 reply; 68+ messages in thread
From: Philip Oakley @ 2021-05-13 10:40 UTC (permalink / raw)
To: Varun Varada, git
Hi Varun,
On 05/04/2021 22:48, Varun Varada wrote:
> There are a bunch of places in the code/docs which use the word "impact"
> incorrectly. This is especially true of places where it says "will not
> impact", which suggests that it might have an effect, albeit not as
> strong of a one. This commit replaces all of these with their
> appropriate alternative so that the docs not only does not use jargon,
> but are also unambiguous.
>
> Signed-off-by: Varun Varada <varuncvarada@gmail.com>
> ---
> Documentation/MyFirstContribution.txt | 2 +-
> Documentation/MyFirstObjectWalk.txt | 2 +-
> Documentation/config/pack.txt | 2 +-
> Documentation/git-fast-import.txt | 14 +++++++-------
> Documentation/git-fetch.txt | 2 +-
> .../technical/hash-function-transition.txt | 2 +-
> Documentation/user-manual.txt | 4 ++--
> advice.c | 2 +-
> builtin/fast-import.c | 2 +-
> builtin/pack-objects.c | 2 +-
> compat/nedmalloc/malloc.c.h | 2 +-
> contrib/coccinelle/README | 2 +-
> dir.c | 2 +-
> t/perf/p5550-fetch-tags.sh | 2 +-
> t/t0008-ignores.sh | 2 +-
> t/t0303-credential-external.sh | 2 +-
> t/t2020-checkout-detach.sh | 4 ++--
> t/t4013-diff-various.sh | 2 +-
> t/t5000-tar-tree.sh | 2 +-
> t/test-lib-functions.sh | 2 +-
> 20 files changed, 28 insertions(+), 28 deletions(-)
I've seen the rather extended discussion about word choice. However Can
I suggest an alternative split of the patch?
If the patch is split between:
1. Test shells
2. Code comments
3. Manual pages
4. Guides and How to's.
then it should be possible to focus on the precision aspects first,
and only later get into the imprecision of modern colloquial English.
For the manual page changes, having a direct link to a test shell or
code comment change would provide important support to the clarification
of any precision aspects of the changes.
Philip
(I'll be off-line for a few days)
Slice the melon before eating.
> diff --git a/Documentation/MyFirstContribution.txt
> b/Documentation/MyFirstContribution.txt
> index af0a9da62e..8372a7e59e 100644
> --- a/Documentation/MyFirstContribution.txt
> +++ b/Documentation/MyFirstContribution.txt
> @@ -592,7 +592,7 @@ Now that you have a usage hint, you can teach Git
> how to show it in the general
> command list shown by `git help git` or `git help -a`, which is generated from
> `command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
> line above it in alphabetical order. Now, we can add some attributes about the
> -command which impacts where it shows up in the aforementioned help
> commands. The
> +command which affects where it shows up in the aforementioned help
> commands. The
> top of `command-list.txt` shares some information about what each attribute
> means; in those help pages, the commands are sorted according to these
> attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
> diff --git a/Documentation/MyFirstObjectWalk.txt
> b/Documentation/MyFirstObjectWalk.txt
> index 2d10eea7a9..fd5bb8fb7d 100644
> --- a/Documentation/MyFirstObjectWalk.txt
> +++ b/Documentation/MyFirstObjectWalk.txt
> @@ -786,7 +786,7 @@ Count all the objects within and modify the print statement:
> By running your walk with and without the filter, you should find
> that the total
> object count in each case is identical. You can also time each invocation of
> the `walken` subcommand, with and without `omitted` being passed in, to confirm
> -to yourself the runtime impact of tracking all omitted objects.
> +to yourself the runtime effect of tracking all omitted objects.
>
> === Changing the Order
>
> diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> index 3da4ea98e2..00fcc9d7c7 100644
> --- a/Documentation/config/pack.txt
> +++ b/Documentation/config/pack.txt
> @@ -55,7 +55,7 @@ pack.deltaCacheSize::
> This cache is used to speed up the writing object phase by not
> having to recompute the final delta result once the best match
> for all objects is found. Repacking large repositories on machines
> - which are tight with memory might be badly impacted by this though,
> + which are tight with memory might be badly affected by this though,
> especially if this cache pushes the system into swapping.
> A value of 0 means no limit. The smallest size of 1 byte may be
> used to virtually disable this cache. Defaults to 256 MiB.
> diff --git a/Documentation/git-fast-import.txt
> b/Documentation/git-fast-import.txt
> index 39cfa05b28..c6d8e4e1d7 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -58,7 +58,7 @@ OPTIONS
> allowing fast-import to access the filesystem outside of the
> repository). These options are disabled by default, but can be
> allowed by providing this option on the command line. This
> - currently impacts only the `export-marks`, `import-marks`, and
> + currently affects only the `export-marks`, `import-marks`, and
> `import-marks-if-exists` feature commands.
> +
> Only enable this option if you trust the program generating the
> @@ -687,7 +687,7 @@ that contains SP the path must be quoted.
>
> A `filecopy` command takes effect immediately. Once the source
> location has been copied to the destination any future commands
> -applied to the source location will not impact the destination of
> +applied to the source location will not affect the destination of
> the copy.
>
> `filerename`
> @@ -708,7 +708,7 @@ that contains SP the path must be quoted.
> A `filerename` command takes effect immediately. Once the source
> location has been renamed to the destination any future commands
> applied to the source location will create new files there and not
> -impact the destination of the rename.
> +affect the destination of the rename.
>
> Note that a `filerename` is the same as a `filecopy` followed by a
> `filedelete` of the source location. There is a slight performance
> @@ -1010,7 +1010,7 @@ The `LF` after the command is optional (it used
> to be required).
> ~~~~~~~~~~
> Causes fast-import to print the entire `progress` line unmodified to
> its standard output channel (file descriptor 1) when the command is
> -processed from the input stream. The command otherwise has no impact
> +processed from the input stream. The command otherwise has no effect
> on the current import, or on any of fast-import's internal state.
>
> ....
> @@ -1035,7 +1035,7 @@ can safely access the refs that fast-import updated.
> ~~~~~~~~~~
> Causes fast-import to print the SHA-1 corresponding to a mark to
> stdout or to the file descriptor previously arranged with the
> -`--cat-blob-fd` argument. The command otherwise has no impact on the
> +`--cat-blob-fd` argument. The command otherwise has no effect on the
> current import; its purpose is to retrieve SHA-1s that later commits
> might want to refer to in their commit messages.
>
> @@ -1050,7 +1050,7 @@ this output safely.
> ~~~~~~~~~~
> Causes fast-import to print a blob to a file descriptor previously
> arranged with the `--cat-blob-fd` argument. The command otherwise
> -has no impact on the current import; its main purpose is to
> +has no effect on the current import; its main purpose is to
> retrieve blobs that may be in fast-import's memory but not
> accessible from the target repository.
>
> @@ -1366,7 +1366,7 @@ code considerably.
>
> The branch LRU builtin to fast-import tends to behave very well, and the
> cost of activating an inactive branch is so low that bouncing around
> -between branches has virtually no impact on import performance.
> +between branches has virtually no effect on import performance.
>
> Handling Renames
> ~~~~~~~~~~~~~~~~
> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> index 9067c2079e..01cf3b3d16 100644
> --- a/Documentation/git-fetch.txt
> +++ b/Documentation/git-fetch.txt
> @@ -113,7 +113,7 @@ on remotes that have themselves deleted those branches.
> If left to accumulate, these stale references might make performance
> worse on big and busy repos that have a lot of branch churn, and
> e.g. make the output of commands like `git branch -a --contains
> -<commit>` needlessly verbose, as well as impacting anything else
> +<commit>` needlessly verbose, as well as affecting anything else
> that'll work with the complete set of known references.
>
> These remote-tracking references can be deleted as a one-off with
> diff --git a/Documentation/technical/hash-function-transition.txt
> b/Documentation/technical/hash-function-transition.txt
> index 7c1630bf83..f4296faffc 100644
> --- a/Documentation/technical/hash-function-transition.txt
> +++ b/Documentation/technical/hash-function-transition.txt
> @@ -42,7 +42,7 @@ mitigations.
>
> If SHA-1 and its variants were to be truly broken, Git's hash function
> could not be considered cryptographically secure any more. This would
> -impact the communication of hash values because we could not trust
> +affect the communication of hash values because we could not trust
> that a given hash value represented the known good version of content
> that the speaker intended.
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index fd480b8645..33c60c49d7 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -302,7 +302,7 @@ Note: checking out 'v2.6.17'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> -state without impacting any branches by performing another switch.
> +state without affecting any branches by performing another switch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command again. Example:
> @@ -1189,7 +1189,7 @@ their histories forked. The work tree is
> overwritten by the result of
> the merge when this combining is done cleanly, or overwritten by a
> half-merged results when this combining results in conflicts.
> Therefore, if you have uncommitted changes touching the same files as
> -the ones impacted by the merge, Git will refuse to proceed. Most of
> +the ones affected by the merge, Git will refuse to proceed. Most of
> the time, you will want to commit your changes before you can merge,
> and if you don't, then linkgit:git-stash[1] can take these changes
> away while you're doing the merge, and reapply them afterwards.
> diff --git a/advice.c b/advice.c
> index 164742305f..9cbbb824a9 100644
> --- a/advice.c
> +++ b/advice.c
> @@ -291,7 +291,7 @@ void detach_advice(const char *new_name)
> "\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/builtin/fast-import.c b/builtin/fast-import.c
> index 3afa81cf9a..24f362d2f4 100644
> --- a/builtin/fast-import.c
> +++ b/builtin/fast-import.c
> @@ -3530,7 +3530,7 @@ int cmd_fast_import(int argc, const char **argv,
> const char *prefix)
> * We don't parse most options until after we've seen the set of
> * "feature" lines at the start of the stream (which allows the command
> * line to override stream data). But we must do an early parse of any
> - * command-line options that impact how we interpret the feature lines.
> + * command-line options that affect how we interpret the feature lines.
> */
> for (i = 1; i < argc; i++) {
> const char *arg = argv[i];
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index 525c2d8552..749bbca241 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -2042,7 +2042,7 @@ static void break_delta_chains(struct object_entry *entry)
> /*
> * Mark ourselves as active and see if the next step causes
> * us to cycle to another active object. It's important to do
> - * this _before_ we loop, because it impacts where we make the
> + * this _before_ we loop, because it affects where we make the
> * cut, and thus how our total_depth counter works.
> * E.g., We may see a partial loop like:
> *
> diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h
> index 814845d4b3..de13121d76 100644
> --- a/compat/nedmalloc/malloc.c.h
> +++ b/compat/nedmalloc/malloc.c.h
> @@ -2952,7 +2952,7 @@ static size_t traverse_and_check(mstate m);
> #endif /* (FOOTERS && !INSECURE) */
>
>
> -/* In gcc, use __builtin_expect to minimize impact of checks */
> +/* In gcc, use __builtin_expect to minimize affect of checks */
> #if !INSECURE
> #if defined(__GNUC__) && __GNUC__ >= 3
> #define RTCHECK(e) __builtin_expect(e, 1)
> diff --git a/contrib/coccinelle/README b/contrib/coccinelle/README
> index f0e80bd7f0..92979ec770 100644
> --- a/contrib/coccinelle/README
> +++ b/contrib/coccinelle/README
> @@ -40,4 +40,4 @@ There are two types of semantic patches:
> are ignored for checks, and can be applied using 'make coccicheck-pending'.
>
> This allows to expose plans of pending large scale refactorings without
> - impacting the bad pattern checks.
> + affecting the bad pattern checks.
> diff --git a/dir.c b/dir.c
> index 3474e67e8f..235e26a90e 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -2144,7 +2144,7 @@ static enum path_treatment
> treat_path_fast(struct dir_struct *dir,
> /*
> * We get path_recurse in the first run when
> * directory_exists_in_index() returns index_nonexistent. We
> - * are sure that new changes in the index does not impact the
> + * are sure that new changes in the index does not affect the
> * outcome. Return now.
> */
> return path_recurse;
> diff --git a/t/perf/p5550-fetch-tags.sh b/t/perf/p5550-fetch-tags.sh
> index d0e0e019ea..1fcb98443c 100755
> --- a/t/perf/p5550-fetch-tags.sh
> +++ b/t/perf/p5550-fetch-tags.sh
> @@ -8,7 +8,7 @@ follows.
>
> The parent repository has a large number of tags which are disconnected from
> the rest of history. That makes them candidates for tag-following, but we never
> -actually grab them (and thus they will impact each subsequent fetch).
> +actually grab them (and thus they will affect each subsequent fetch).
>
> The child repository is a clone of parent, without the tags, and is at least
> one commit behind the parent (meaning that we will fetch one object and then
> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> index a594b4aa7d..95daba4000 100755
> --- a/t/t0008-ignores.sh
> +++ b/t/t0008-ignores.sh
> @@ -315,7 +315,7 @@ test_expect_success_multi 'needs work tree' '' '
> # test standard ignores
>
> # First make sure that the presence of a file in the working tree
> -# does not impact results, but that the presence of a file in the
> +# does not affect results, but that the presence of a file in the
> # index does unless the --no-index option is used.
>
> for subdir in '' 'a/'
> diff --git a/t/t0303-credential-external.sh b/t/t0303-credential-external.sh
> index f028fd1418..a9348f655a 100755
> --- a/t/t0303-credential-external.sh
> +++ b/t/t0303-credential-external.sh
> @@ -41,7 +41,7 @@ test -z "$GIT_TEST_CREDENTIAL_HELPER_SETUP" ||
> eval "$GIT_TEST_CREDENTIAL_HELPER_SETUP"
>
> # clean before the test in case there is cruft left
> -# over from a previous run that would impact results
> +# over from a previous run that would affect results
> helper_test_clean "$GIT_TEST_CREDENTIAL_HELPER"
>
> helper_test "$GIT_TEST_CREDENTIAL_HELPER"
> diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
> index bc46713a43..568c258c5a 100755
> --- a/t/t2020-checkout-detach.sh
> +++ b/t/t2020-checkout-detach.sh
> @@ -202,7 +202,7 @@ test_expect_success 'describe_detached_head prints
> no SHA-1 ellipsis when not as
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> - state without impacting any branches by switching back to a branch.
> + state without affecting any branches by switching back to a branch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command. Example:
> @@ -284,7 +284,7 @@ test_expect_success 'describe_detached_head does
> print SHA-1 ellipsis when asked
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> - state without impacting any branches by switching back to a branch.
> + state without affecting any branches by switching back to a branch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command. Example:
> diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> index 6cca8b84a6..97365a7786 100755
> --- a/t/t4013-diff-various.sh
> +++ b/t/t4013-diff-various.sh
> @@ -109,7 +109,7 @@ test_expect_success setup '
> git checkout -f master &&
>
> # Same merge as master, but with parents reversed. Hide it in a
> - # pseudo-ref to avoid impacting tests with --all.
> + # pseudo-ref to avoid affecting tests with --all.
> commit=$(echo reverse |
> git commit-tree -p master^2 -p master^1 master^{tree}) &&
> git update-ref REVERSE $commit &&
> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> index 7204799a0b..33a6efce2f 100755
> --- a/t/t5000-tar-tree.sh
> +++ b/t/t5000-tar-tree.sh
> @@ -379,7 +379,7 @@ test_expect_success 'catch non-matching pathspec' '
> # Pull the size and date of each entry in a tarfile using the system tar.
> #
> # We'll pull out only the year from the date; that avoids any question of
> -# timezones impacting the result (as long as we keep our test times away from a
> +# timezones affecting the result (as long as we keep our test times away from a
> # year boundary; our reference times are all in August).
> #
> # The output of tar_info is expected to be "<size> <year>", both in decimal. It
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index 6348e8d733..ff65f86f50 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -1379,7 +1379,7 @@ mingw_read_file_strip_cr_ () {
> }
>
> # Like "env FOO=BAR some-program", but run inside a subshell, which means
> -# it also works for shell functions (though those functions cannot impact
> +# it also works for shell functions (though those functions cannot affect
> # the environment outside of the test_env invocation).
> test_env () {
> (
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-13 9:48 ` Michal Suchánek
2021-05-13 9:59 ` Felipe Contreras
@ 2021-05-26 23:49 ` Varun Varada
2021-05-27 11:46 ` Michal Suchánek
1 sibling, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-05-26 23:49 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Robert Coup, Felipe Contreras, git
On Thu, 13 May 2021 at 04:48, Michal Suchánek <msuchanek@suse.de> wrote:
> Yet Felipe insists that 'impact' is somehow generally bad word to use or
> that it should be abolished solely because he finds it bad and nobody
> objected to the alternative wording.
>
> Opinions on use of 'impact' differ both among the participants of this
> discussion and authorities like authors well-known dictionaries.
>
> It looks like this is generally matter of stylistic preferences and
> opinions. That is even if there is some slight stylistic preference for
> not using the word 'impact' it is very hard to prove such and then it is
> very hard to request change based only on writing style preferences.
The argument is not that it is generally a bad word to use, but that
it is generally bad to use words when they don't mean what one thinks
they mean, especially when all evidence says otherwise.
All major dictionaries define "impact" as "a strong effect" or "to
affect strongly". This is not style, but semantics. In the same way
that "per se" being used to mean "necessarily" is not a style issue,
using "impact" to mean "an effect" or "to affect" is not a style
issue.
As has been stated already, the clear and substantial argument for
this change is that it reduces the confusion that arises from
improperly using the word "impact" in the instances without any loss
or compromise in meaning. That is a clear win.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-13 10:40 ` Philip Oakley
@ 2021-05-26 23:52 ` Varun Varada
2021-05-27 11:20 ` Philip Oakley
0 siblings, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-05-26 23:52 UTC (permalink / raw)
To: Philip Oakley; +Cc: git
On Thu, 13 May 2021 at 05:40, Philip Oakley <philipoakley@iee.email> wrote:
>
> Hi Varun,
>
>
> I've seen the rather extended discussion about word choice. However Can
> I suggest an alternative split of the patch?
>
> If the patch is split between:
> 1. Test shells
> 2. Code comments
> 3. Manual pages
> 4. Guides and How to's.
> then it should be possible to focus on the precision aspects first,
> and only later get into the imprecision of modern colloquial English.
> For the manual page changes, having a direct link to a test shell or
> code comment change would provide important support to the clarification
> of any precision aspects of the changes.
I'd be happy to split it, but I'm not sure I follow what you mean by
"precision aspects".
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-26 23:52 ` Varun Varada
@ 2021-05-27 11:20 ` Philip Oakley
0 siblings, 0 replies; 68+ messages in thread
From: Philip Oakley @ 2021-05-27 11:20 UTC (permalink / raw)
To: Varun Varada; +Cc: git
On 27/05/2021 00:52, Varun Varada wrote:
> On Thu, 13 May 2021 at 05:40, Philip Oakley <philipoakley@iee.email> wrote:
>> Hi Varun,
>>
>>
>> I've seen the rather extended discussion about word choice. However Can
>> I suggest an alternative split of the patch?
>>
>> If the patch is split between:
>> 1. Test shells
>> 2. Code comments
>> 3. Manual pages
>> 4. Guides and How to's.
>> then it should be possible to focus on the precision aspects first,
>> and only later get into the imprecision of modern colloquial English.
>> For the manual page changes, having a direct link to a test shell or
>> code comment change would provide important support to the clarification
>> of any precision aspects of the changes.
> I'd be happy to split it, but I'm not sure I follow what you mean by
> "precision aspects".
Hi, I was using precision in a similar way to the accuracy/precision
sense that you had highlighted about affect/effect not really being
interchangeable (i.e. my 'precision' is similarly inexact;-).
You are right that there is a distinct difference between affect/effect
for the grammar pedants and that in the vernacular (common) usage,
because of the many dialects and vocalisation here in UK (and likely the
Americas), many folk ignore the spelling (esp if spoken;-) and just look
for context.
My suggestion was to start with just the test/code comments where it is
likely easier to identify and describe the affect/effect mistakes
(accurately and precisely). By splitting the patches into separate Test
and Code changes each review gets smaller and easier.
Then, for each of the test and code patch, see if there is a (~exactly)
matching issue in the documentation. These can then (hopefully) easily
be justified by reference to their code/test change.
This should leave a few (~small amount ;-) of residual affect/effect
potential changes to be discussed/argued over.
Philip
[the _average_ number of residual changes won't be an integer, so maybe
it is a small amount of changes]
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-26 23:49 ` Varun Varada
@ 2021-05-27 11:46 ` Michal Suchánek
2021-05-27 14:08 ` Felipe Contreras
0 siblings, 1 reply; 68+ messages in thread
From: Michal Suchánek @ 2021-05-27 11:46 UTC (permalink / raw)
To: Varun Varada; +Cc: Robert Coup, Felipe Contreras, git
On Wed, May 26, 2021 at 06:49:58PM -0500, Varun Varada wrote:
> On Thu, 13 May 2021 at 04:48, Michal Suchánek <msuchanek@suse.de> wrote:
> > Yet Felipe insists that 'impact' is somehow generally bad word to use or
> > that it should be abolished solely because he finds it bad and nobody
> > objected to the alternative wording.
> >
> > Opinions on use of 'impact' differ both among the participants of this
> > discussion and authorities like authors well-known dictionaries.
> >
> > It looks like this is generally matter of stylistic preferences and
> > opinions. That is even if there is some slight stylistic preference for
> > not using the word 'impact' it is very hard to prove such and then it is
> > very hard to request change based only on writing style preferences.
>
> The argument is not that it is generally a bad word to use, but that
> it is generally bad to use words when they don't mean what one thinks
> they mean, especially when all evidence says otherwise.
Not all evidence. There are people who think the use is fine.
>
> All major dictionaries define "impact" as "a strong effect" or "to
> affect strongly". This is not style, but semantics. In the same way
Not all dictionaries, actually. And when there is no meaningful
difference between "strong efffect" and "effect" using word that means
one or the other is just style.`
> that "per se" being used to mean "necessarily" is not a style issue,
> using "impact" to mean "an effect" or "to affect" is not a style
> issue.
>
> As has been stated already, the clear and substantial argument for
> this change is that it reduces the confusion that arises from
> improperly using the word "impact" in the instances without any loss
There is no final authority on 'correct' word use in English.
Authorities and readers disagree. In some cases local language variation
disagrees so completely that no use is correct everywhere - eg. color vs
colour.
We should learn to work together with people that use different
variant of the language rather than insist that the variant that I or my
teacher uses is the only correct one and everyone else should use it.
Thanks
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-27 11:46 ` Michal Suchánek
@ 2021-05-27 14:08 ` Felipe Contreras
2021-05-27 14:35 ` Michal Suchánek
0 siblings, 1 reply; 68+ messages in thread
From: Felipe Contreras @ 2021-05-27 14:08 UTC (permalink / raw)
To: Michal Suchánek, Varun Varada; +Cc: Robert Coup, Felipe Contreras, git
Michal Suchánek wrote:
> On Wed, May 26, 2021 at 06:49:58PM -0500, Varun Varada wrote:
> > On Thu, 13 May 2021 at 04:48, Michal Suchánek <msuchanek@suse.de> wrote:
> > > Yet Felipe insists that 'impact' is somehow generally bad word to use or
> > > that it should be abolished solely because he finds it bad and nobody
> > > objected to the alternative wording.
> > >
> > > Opinions on use of 'impact' differ both among the participants of this
> > > discussion and authorities like authors well-known dictionaries.
> > >
> > > It looks like this is generally matter of stylistic preferences and
> > > opinions. That is even if there is some slight stylistic preference for
> > > not using the word 'impact' it is very hard to prove such and then it is
> > > very hard to request change based only on writing style preferences.
> >
> > The argument is not that it is generally a bad word to use, but that
> > it is generally bad to use words when they don't mean what one thinks
> > they mean, especially when all evidence says otherwise.
>
> Not all evidence. There are people who think the use is fine.
What people think is not evidence.
There's people who think the Earth is flat.
> > All major dictionaries define "impact" as "a strong effect" or "to
> > affect strongly". This is not style, but semantics. In the same way
>
> Not all dictionaries, actually.
You don't need all dictionaries.
If 50% of trials show a drug is safe, and 50% show it's not, you don't
approve bit because "not all say say it's unsafe".
If there's evidence that A is bad, you should consider avoiding A,
especially when you have B, and you have *zero* evidence showing B is
bad.
> > that "per se" being used to mean "necessarily" is not a style issue,
> > using "impact" to mean "an effect" or "to affect" is not a style
> > issue.
> >
> > As has been stated already, the clear and substantial argument for
> > this change is that it reduces the confusion that arises from
> > improperly using the word "impact" in the instances without any loss
>
> There is no final authority on 'correct' word use in English.
You don't need a final authority.
There is evidence that A is problematic.
> We should learn to work together with people that use different
> variant of the language rather than insist that the variant that I or my
> teacher uses is the only correct one and everyone else should use it.
Except one variant is problematic, and the other is not.
Do you have *ANY* evidence that shows a problem with "effect"?
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-27 14:08 ` Felipe Contreras
@ 2021-05-27 14:35 ` Michal Suchánek
2021-05-27 16:43 ` Felipe Contreras
2021-06-12 23:13 ` Varun Varada
0 siblings, 2 replies; 68+ messages in thread
From: Michal Suchánek @ 2021-05-27 14:35 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, Robert Coup, git
On Thu, May 27, 2021 at 09:08:25AM -0500, Felipe Contreras wrote:
> Michal Suchánek wrote:
> > On Wed, May 26, 2021 at 06:49:58PM -0500, Varun Varada wrote:
> > > On Thu, 13 May 2021 at 04:48, Michal Suchánek <msuchanek@suse.de> wrote:
> > > > Yet Felipe insists that 'impact' is somehow generally bad word to use or
> > > > that it should be abolished solely because he finds it bad and nobody
> > > > objected to the alternative wording.
> > > >
> > > > Opinions on use of 'impact' differ both among the participants of this
> > > > discussion and authorities like authors well-known dictionaries.
> > > >
> > > > It looks like this is generally matter of stylistic preferences and
> > > > opinions. That is even if there is some slight stylistic preference for
> > > > not using the word 'impact' it is very hard to prove such and then it is
> > > > very hard to request change based only on writing style preferences.
> > >
> > > The argument is not that it is generally a bad word to use, but that
> > > it is generally bad to use words when they don't mean what one thinks
> > > they mean, especially when all evidence says otherwise.
> >
> > Not all evidence. There are people who think the use is fine.
>
> What people think is not evidence.
>
> There's people who think the Earth is flat.
And there's people who think it's not ok to use 'impact' as synonym for
effect/affect, too.
>
> > > All major dictionaries define "impact" as "a strong effect" or "to
> > > affect strongly". This is not style, but semantics. In the same way
> >
> > Not all dictionaries, actually.
>
> You don't need all dictionaries.
>
> If 50% of trials show a drug is safe, and 50% show it's not, you don't
> approve bit because "not all say say it's unsafe".
>
> If there's evidence that A is bad, you should consider avoiding A,
> especially when you have B, and you have *zero* evidence showing B is
> bad.
Indeed, but what the dictionaries provide is a definition.
Based on the definition some people think it's not OK, and some people
think it's OK.
That's only opinion, not evidence.
>
> > > that "per se" being used to mean "necessarily" is not a style issue,
> > > using "impact" to mean "an effect" or "to affect" is not a style
> > > issue.
> > >
> > > As has been stated already, the clear and substantial argument for
> > > this change is that it reduces the confusion that arises from
> > > improperly using the word "impact" in the instances without any loss
> >
> > There is no final authority on 'correct' word use in English.
>
> You don't need a final authority.
>
> There is evidence that A is problematic.
So we should stop using words that have different spelling in British
and American English because no matter what spelling you choose somebody
can find it 'problematic'?
>
> > We should learn to work together with people that use different
> > variant of the language rather than insist that the variant that I or my
> > teacher uses is the only correct one and everyone else should use it.
>
> Except one variant is problematic, and the other is not.
>
>
> Do you have *ANY* evidence that shows a problem with "effect"?
I find problem with the proposition that 'impact' should be replaced
with 'effect' based solely on the opinion that use of 'impact' is
somehow inferior.
This will bring in reviews that focus on hairsplitting when the
formulation with 'impact' reads better than 'effect' and where the
change does not make it read any better so it should not be changed.
It also brings in reviews of the sort that simply say that use of
'impact' is OK, and there is no need to change.
You can reason the change in different, more objective ways. You
refuse and insist that people acknowledge that the use of 'impact' is
wrong. It is not universally true in the same way that writing neither
'color' nor 'colour' is not universally correct.
Also I have so far not seen any real evidence that 'impact' is in fact
used incorrectly, only some opinions and reference to a style guide.
So if you want to compare to physicians and drug trials how many
double-blind studies on the effect of the use of word 'impact' can you
refer to?
Thanks
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-27 14:35 ` Michal Suchánek
@ 2021-05-27 16:43 ` Felipe Contreras
2021-06-12 23:13 ` Varun Varada
1 sibling, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-05-27 16:43 UTC (permalink / raw)
To: Michal Suchánek, Felipe Contreras; +Cc: Varun Varada, Robert Coup, git
Michal Suchánek wrote:
> On Thu, May 27, 2021 at 09:08:25AM -0500, Felipe Contreras wrote:
> > Do you have *ANY* evidence that shows a problem with "effect"?
>
> I find problem with the proposition that 'impact' should be replaced
> with 'effect'...
Do not avoid the question.
Answer the question being asked.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-05-27 14:35 ` Michal Suchánek
2021-05-27 16:43 ` Felipe Contreras
@ 2021-06-12 23:13 ` Varun Varada
2021-06-13 11:40 ` Michal Suchánek
1 sibling, 1 reply; 68+ messages in thread
From: Varun Varada @ 2021-06-12 23:13 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Felipe Contreras, Robert Coup, git
On Thu, 27 May 2021 at 09:35, Michal Suchánek <msuchanek@suse.de> wrote:
>
> > > Not all evidence. There are people who think the use is fine.
> >
> > What people think is not evidence.
> >
> > There's people who think the Earth is flat.
>
> And there's people who think it's not ok to use 'impact' as synonym for
> effect/affect, too.
This is not because they *think* this, but because it's demonstrably
true. The words are not synonyms according to any reputable
dictionaries, as shown already.
>
> Indeed, but what the dictionaries provide is a definition.
>
> Based on the definition some people think it's not OK, and some people
> think it's OK.
>
> That's only opinion, not evidence.
Hence, the dictionary definitions, which are evidence. If people are
confused as to what the words within the definition mean, they can
then recursively refer to the definitions of those words within the
definition. Unless you're implying that most of the dictionaries
referenced here are prescriptive (which they're not), then what the
dictionaries say are the definitions of words are results of the
linguists of those dictionaries going around and documenting what the
words mean, with ample historical and etymological evidence to back
it.
People having opinions about said definitions is, like you said, only
opinion and not evidence. All evidence points to the fact that the
words are not synonyms.
> >
> > > > that "per se" being used to mean "necessarily" is not a style issue,
> > > > using "impact" to mean "an effect" or "to affect" is not a style
> > > > issue.
> > > >
> > > > As has been stated already, the clear and substantial argument for
> > > > this change is that it reduces the confusion that arises from
> > > > improperly using the word "impact" in the instances without any loss
> > >
> > > There is no final authority on 'correct' word use in English.
Yes, there essentially is. It's called a dictionary. If you don't
respect the value of dictionaries, you're tacitly claiming that anyone
can use words in any which way they want and they would be correct in
doing so. E.g., someone can use "hello" to mean "goodbye" and be
correct because there's no so-called authority.
> >
> > You don't need a final authority.
> >
> > There is evidence that A is problematic.
>
> So we should stop using words that have different spelling in British
> and American English because no matter what spelling you choose somebody
> can find it 'problematic'?
No, because practically every dictionary on the planet acknowledges
when spelling differences exist and which spellings correspond to
identical words (e.g., "colour" and "color" mean the same thing in all
contexts).
>
> >
> > > We should learn to work together with people that use different
> > > variant of the language rather than insist that the variant that I or my
> > > teacher uses is the only correct one and everyone else should use it.
> >
> > Except one variant is problematic, and the other is not.
> >
> >
> > Do you have *ANY* evidence that shows a problem with "effect"?
>
> I find problem with the proposition that 'impact' should be replaced
> with 'effect' based solely on the opinion that use of 'impact' is
> somehow inferior.
It's not "somehow inferior". No one is waving their hands arbitrarily;
it's already been discussed precisely how the word is inappropriate.
>
> This will bring in reviews that focus on hairsplitting when the
> formulation with 'impact' reads better than 'effect' and where the
> change does not make it read any better so it should not be changed.
>
> It also brings in reviews of the sort that simply say that use of
> 'impact' is OK, and there is no need to change.
That's an "if". This, however, is a situation where multiple people
have already voiced concerns about it being a problem. And it's not
hairsplitting; not at all, in fact. It's genuinely confusing.
>
> You can reason the change in different, more objective ways. You
> refuse and insist that people acknowledge that the use of 'impact' is
> wrong. It is not universally true in the same way that writing neither
> 'color' nor 'colour' is not universally correct.
It's clear by now that you are not fundamentally against the change
either, but are merely arguing about what reason one should "report to
the world" for why this change was made. I've already stated that we
don't need to agree on what the reason is since the end result will be
the same. Please stop this pedantic and frankly pointless discussion
about a hypothetical about what future people might think; it's
becoming exhausting. This is a change that (evidently) multiple people
in the present have brought up as an issue, so it needs solving now.
> Also I have so far not seen any real evidence that 'impact' is in fact
> used incorrectly, only some opinions and reference to a style guide.
If you don't consider dictionaries and style guides to be evidence,
then I don't know what counts as evidence.
Varun
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-06-12 23:13 ` Varun Varada
@ 2021-06-13 11:40 ` Michal Suchánek
2021-06-13 14:06 ` Felipe Contreras
0 siblings, 1 reply; 68+ messages in thread
From: Michal Suchánek @ 2021-06-13 11:40 UTC (permalink / raw)
To: Varun Varada; +Cc: Felipe Contreras, Robert Coup, git
On Sat, Jun 12, 2021 at 06:13:02PM -0500, Varun Varada wrote:
> On Thu, 27 May 2021 at 09:35, Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > > > Not all evidence. There are people who think the use is fine.
> > >
> > > What people think is not evidence.
> > >
> > > There's people who think the Earth is flat.
> >
> > And there's people who think it's not ok to use 'impact' as synonym for
> > effect/affect, too.
>
> This is not because they *think* this, but because it's demonstrably
> true. The words are not synonyms according to any reputable
> dictionaries, as shown already.
>
> >
> > Indeed, but what the dictionaries provide is a definition.
> >
> > Based on the definition some people think it's not OK, and some people
> > think it's OK.
> >
> > That's only opinion, not evidence.
>
> Hence, the dictionary definitions, which are evidence. If people are
The dictionaries provide definition, not usage guidelines.
Fabricating usage guildelines from sources that do not provide them is
opinion, not evidence.
> confused as to what the words within the definition mean, they can
Two people. That's called 'anecdotal evidence'. You will find anecdotal
evidence in favor of pretty much anything possible, that does not mean
it's in any way common.
>
> > >
> > > > > that "per se" being used to mean "necessarily" is not a style issue,
> > > > > using "impact" to mean "an effect" or "to affect" is not a style
> > > > > issue.
> > > > >
> > > > > As has been stated already, the clear and substantial argument for
> > > > > this change is that it reduces the confusion that arises from
> > > > > improperly using the word "impact" in the instances without any loss
> > > >
> > > > There is no final authority on 'correct' word use in English.
>
> Yes, there essentially is. It's called a dictionary. If you don't
> respect the value of dictionaries, you're tacitly claiming that anyone
I don't consider opinions tangentially related to dictionary content a
proof of anything.
Also it has been pointed out that dictionaries don't agree on the
precise definition - hence no final authority. The laguage use varies,
and dictionaries also reflect that. Even the use of word 'impact'.
>
> >
> > This will bring in reviews that focus on hairsplitting when the
> > formulation with 'impact' reads better than 'effect' and where the
> > change does not make it read any better so it should not be changed.
> >
> > It also brings in reviews of the sort that simply say that use of
> > 'impact' is OK, and there is no need to change.
>
> That's an "if". This, however, is a situation where multiple people
We already received such reviews as response to your patch. It's not
what-if.
Best regards
Michal
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-06-13 11:40 ` Michal Suchánek
@ 2021-06-13 14:06 ` Felipe Contreras
2021-06-13 16:28 ` Michal Suchánek
0 siblings, 1 reply; 68+ messages in thread
From: Felipe Contreras @ 2021-06-13 14:06 UTC (permalink / raw)
To: Michal Suchánek, Varun Varada; +Cc: Felipe Contreras, Robert Coup, git
Michal Suchánek wrote:
> On Sat, Jun 12, 2021 at 06:13:02PM -0500, Varun Varada wrote:
> > On Thu, 27 May 2021 at 09:35, Michal Suchánek <msuchanek@suse.de> wrote:
> > > That's only opinion, not evidence.
> >
> > Hence, the dictionary definitions, which are evidence. If people are
>
> The dictionaries provide definition, not usage guidelines.
What do you think definitions are?
A definition is there because many people use the word that way.
> > Yes, there essentially is. It's called a dictionary. If you don't
> > respect the value of dictionaries, you're tacitly claiming that anyone
>
> I don't consider opinions tangentially related to dictionary content a
> proof of anything.
>
> Also it has been pointed out that dictionaries don't agree on the
> precise definition - hence no final authority. The laguage use varies,
> and dictionaries also reflect that. Even the use of word 'impact'.
You need to understand what dictionaries do: they describe current
usage.
If some dictionaries say "impact" and "affect" are not 100% synonyms,
that means some people don't consider "impact" and "affect" to be
synonymns.
Period.
> > > This will bring in reviews that focus on hairsplitting when the
> > > formulation with 'impact' reads better than 'effect' and where the
> > > change does not make it read any better so it should not be changed.
> > >
> > > It also brings in reviews of the sort that simply say that use of
> > > 'impact' is OK, and there is no need to change.
> >
> > That's an "if". This, however, is a situation where multiple people
>
> We already received such reviews as response to your patch. It's not
> what-if.
In case you haven't been following this thread closely, you are the only
person that says the use of "impact" is OK. One person said "impact" was
OK for him, but he didn't say anything of anybody else. Another person
asked if they were synonyms. That's it.
I say Varun should resend the patch separate from all other patches,
explain why they aren't synonyms and mention for the record that one
person objects to the change.
It's OK to merge patches where one person objects.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-06-13 14:06 ` Felipe Contreras
@ 2021-06-13 16:28 ` Michal Suchánek
2021-06-13 17:12 ` Felipe Contreras
0 siblings, 1 reply; 68+ messages in thread
From: Michal Suchánek @ 2021-06-13 16:28 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Varun Varada, Robert Coup, git
On Sun, Jun 13, 2021 at 09:06:40AM -0500, Felipe Contreras wrote:
> Michal Suchánek wrote:
> > On Sat, Jun 12, 2021 at 06:13:02PM -0500, Varun Varada wrote:
>
> > > > This will bring in reviews that focus on hairsplitting when the
> > > > formulation with 'impact' reads better than 'effect' and where the
> > > > change does not make it read any better so it should not be changed.
> > > >
> > > > It also brings in reviews of the sort that simply say that use of
> > > > 'impact' is OK, and there is no need to change.
> > >
> > > That's an "if". This, however, is a situation where multiple people
> >
> > We already received such reviews as response to your patch. It's not
> > what-if.
>
> In case you haven't been following this thread closely, you are the only
> person that says the use of "impact" is OK. One person said "impact" was
Apparently you have not followed this thread closely yourself.
> OK for him, but he didn't say anything of anybody else. Another person
> asked if they were synonyms. That's it.
>
> I say Varun should resend the patch separate from all other patches,
> explain why they aren't synonyms and mention for the record that one
> person objects to the change.
No if he really wants the thing merged he should resend the patch with
proper reasoning how replacing the word 'impact' improves the
documentation and perhaps say for the record that two people find the
word confusing.
>
> It's OK to merge patches where one person objects.
Apprantly you also missed that I am not opposed to the patch.
Best regards
Michal
>
> --
> Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect"
2021-06-13 16:28 ` Michal Suchánek
@ 2021-06-13 17:12 ` Felipe Contreras
0 siblings, 0 replies; 68+ messages in thread
From: Felipe Contreras @ 2021-06-13 17:12 UTC (permalink / raw)
To: Michal Suchánek, Felipe Contreras; +Cc: Varun Varada, Robert Coup, git
Michal Suchánek wrote:
> On Sun, Jun 13, 2021 at 09:06:40AM -0500, Felipe Contreras wrote:
> > Michal Suchánek wrote:
> > > We already received such reviews as response to your patch. It's not
> > > what-if.
> >
> > In case you haven't been following this thread closely, you are the only
> > person that says the use of "impact" is OK. One person said "impact" was
>
> Apparently you have not followed this thread closely yourself.
I have. If you think you have, then list all the people that agree with
you that there's no problem with "impact" for the general population.
> > It's OK to merge patches where one person objects.
>
> Apprantly you also missed that I am not opposed to the patch.
Good. So some people are in favor of the patch, and nobody is against
it.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 68+ messages in thread
end of thread, other threads:[~2021-06-13 17:13 UTC | newest]
Thread overview: 68+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-05 21:48 [PATCH] doc: replace jargon word "impact" with "effect"/"affect" Varun Varada
2021-04-06 9:24 ` Michal Suchánek
2021-04-06 19:36 ` Varun Varada
2021-04-06 23:01 ` Jeff King
2021-04-07 0:06 ` Varun Varada
2021-04-28 0:39 ` Varun Varada
2021-04-28 8:58 ` Michal Suchánek
2021-04-28 18:15 ` Varun Varada
2021-04-28 18:49 ` Michal Suchánek
2021-04-30 1:51 ` Varun Varada
2021-04-30 7:59 ` Michal Suchánek
2021-05-10 17:19 ` Varun Varada
2021-05-10 17:35 ` Michal Suchánek
2021-05-10 18:37 ` Varun Varada
2021-05-11 10:43 ` Michal Suchánek
2021-05-11 13:22 ` Junio C Hamano
2021-05-12 3:02 ` Felipe Contreras
2021-05-12 2:59 ` Felipe Contreras
2021-05-12 2:48 ` Felipe Contreras
2021-05-12 2:38 ` Felipe Contreras
2021-05-12 2:34 ` Felipe Contreras
2021-05-12 2:24 ` Felipe Contreras
2021-05-11 19:59 ` Felipe Contreras
2021-05-11 20:25 ` Michal Suchánek
2021-05-11 21:38 ` Varun Varada
2021-05-12 3:43 ` Felipe Contreras
2021-05-12 4:09 ` Michal Suchánek
2021-05-12 5:13 ` Felipe Contreras
2021-05-12 6:47 ` Michal Suchánek
2021-05-12 9:06 ` Felipe Contreras
2021-05-12 10:08 ` Michal Suchánek
2021-05-12 10:33 ` Michal Suchánek
2021-05-12 11:05 ` Felipe Contreras
2021-05-12 11:20 ` Michal Suchánek
2021-05-12 11:45 ` Robert P. J. Day
2021-05-12 15:19 ` Kerry, Richard
2021-05-12 16:47 ` Varun Varada
2021-05-12 17:01 ` Michal Suchánek
2021-05-12 17:32 ` Felipe Contreras
2021-05-12 18:04 ` Michal Suchánek
2021-05-12 19:42 ` Felipe Contreras
2021-05-13 7:46 ` Michal Suchánek
2021-05-13 8:28 ` Felipe Contreras
2021-05-13 8:55 ` Robert Coup
2021-05-13 9:48 ` Michal Suchánek
2021-05-13 9:59 ` Felipe Contreras
2021-05-26 23:49 ` Varun Varada
2021-05-27 11:46 ` Michal Suchánek
2021-05-27 14:08 ` Felipe Contreras
2021-05-27 14:35 ` Michal Suchánek
2021-05-27 16:43 ` Felipe Contreras
2021-06-12 23:13 ` Varun Varada
2021-06-13 11:40 ` Michal Suchánek
2021-06-13 14:06 ` Felipe Contreras
2021-06-13 16:28 ` Michal Suchánek
2021-06-13 17:12 ` Felipe Contreras
2021-05-12 22:52 ` Varun Varada
2021-05-13 6:19 ` Felipe Contreras
2021-05-12 3:21 ` Felipe Contreras
2021-05-11 19:21 ` Felipe Contreras
2021-05-11 19:57 ` Michal Suchánek
2021-05-12 3:09 ` Felipe Contreras
2021-05-12 4:11 ` Michal Suchánek
2021-05-12 5:22 ` Felipe Contreras
2021-05-12 16:39 ` Varun Varada
2021-05-13 10:40 ` Philip Oakley
2021-05-26 23:52 ` Varun Varada
2021-05-27 11:20 ` Philip Oakley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).