patchdoc: replace jargon word "impact" with "effect"/"affect"

> 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
> 

>
> 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
> >

> > 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 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]

> --- 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)

>
> 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).

> 
>  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

>
> 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.

>
> 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

> 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

>
> 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

> 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

>
> 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.

>
> >
> > >
> > > >
> > > > >
> > > > > 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

> 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.

> 
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > 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

>
> 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.

>
> >
> > >
> > > 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.

>
> 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

> 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?

> 
> >
> > 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
> 
> >
> > > 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
> 

> 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.

> > > 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.

> 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.

> > 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.

> 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.

> 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.

> 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.

> 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.

>
> 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?

> 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.

> > > 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?"

> 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).

> 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.

> 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.

> > > 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.

> > 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?

> 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.

> 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?

> 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.

> 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."

> 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

> 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.

> 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.

>
> 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.

> 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).

> 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.

> 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.

> 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.

> 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?

> 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.

> 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?

> 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.

> 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.

> 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

> 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.

> > 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.

> 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"?

> 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'...

>
> > > 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.

>
> 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.

> 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

> 
> > >
> > > > > 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

> 
> >
> > 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

> > > That's only opinion, not evidence.
> > 
> > Hence, the dictionary definitions, which are evidence. If people are
> 
> The dictionaries provide definition, not usage guidelines.

> > 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.

> 
> > > > 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.

> > > 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.

>
> 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.

> 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.

> > 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?

> 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".

> 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.

> > > 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?

> 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".

> 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.

>
> 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?

> 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 () {
>    (

>
> 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.

> 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".