From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59860C433ED for ; Mon, 10 May 2021 18:37:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2689961466 for ; Mon, 10 May 2021 18:37:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232021AbhEJSjD (ORCPT ); Mon, 10 May 2021 14:39:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230186AbhEJSjC (ORCPT ); Mon, 10 May 2021 14:39:02 -0400 Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6080FC061574 for ; Mon, 10 May 2021 11:37:57 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id k25so16697671oic.4 for ; Mon, 10 May 2021 11:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=98rjl7CysezjYFLvGUGoT3bIXK7kw6ofRJ1XtzmcXOI=; b=aniAqa5WJkOhen4vIQsY4UOsvZUlxS0cG6eD96/Q1rfAaPq3KKymxiqOUUbgFVLniG Lo0mZCOK6y5PcCmMdLYTLJlDgoyASBaDh1sxGreosOaiYIxo4CwIKmEoSs7TNj03jKLa nDIQFVzXmE/nFSNwn0bpWLiAUOsra6apSVxzmay86Ko9hQi8D5yQehut89H2KxpGVQ3I 6lOFqzHByay+4i/RSHMWfL1QpuAQbp2QQ2Z58X0rJuZJic2E3Ombxp3Zj8G0I3+5G6bx uNWrP81FESXGZ9zOAsXDCYFOaFwsbpLZYrstKy+/aylu+7WXulf3N0ck4si/8aaZ5EBS iv1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=98rjl7CysezjYFLvGUGoT3bIXK7kw6ofRJ1XtzmcXOI=; b=XZTkuoU+ZC+i/f03XoS0hfiYisHrhbSLQC4zQB+VllZiBwdcFlzQ7/9LfyJeSPswXF AMVL1/gU5HGxKOFn0Pa74RVYH4M3MdW82dq9rO97Km5cMGUaBqKkgpHb86mh6XD078hc e8iJPMMnBE42Xfg//axZNDRPQ6NC9QsIqhpbyXqLD0A22nvhlhN2+ZE2Nirc6UaGTpsR VrATxqEPH6hMaW0zwGN4w/7E+NEZ/UlGkdX846HCwa1ywiFBIFiw/21yzcUad6i6s7yl ZqG7ijvNb+zy9lPvhuBtrpaGyktMwO0OUvIUtjK2Jr+8tOVanp10HG27BKSA0Lmsb5+6 ltCQ== X-Gm-Message-State: AOAM530dD+PkAwNVJwQniei2ZQFJUImBRxkaWPD2lvTKpU2/fSvYETfC 34W3LtFJPJNOSLNKEHjS3nK0ACcEcxjRjB+AL7zL04fnhbg= X-Google-Smtp-Source: ABdhPJzJYDY2fv1t/G5r0tNMt0nXNsFy5JF1p3MFewXbKGGWFW/+R3M1M+arHJEWmpNtqef1+TTNw5QxEYM5LduR2NQ= X-Received: by 2002:aca:c183:: with SMTP id r125mr4975321oif.147.1620671876393; Mon, 10 May 2021 11:37:56 -0700 (PDT) MIME-Version: 1.0 References: <20210428085838.GN6564@kitsune.suse.cz> <20210428184956.GS6564@kitsune.suse.cz> <20210430075924.GB6564@kitsune.suse.cz> <20210510173502.GH12700@kitsune.suse.cz> In-Reply-To: <20210510173502.GH12700@kitsune.suse.cz> From: Varun Varada Date: Mon, 10 May 2021 13:37:45 -0500 Message-ID: Subject: Re: [PATCH] doc: replace jargon word "impact" with "effect"/"affect" To: =?UTF-8?Q?Michal_Such=C3=A1nek?= Cc: Jeff King , git@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Mon, 10 May 2021 at 12:35, Michal Such=C3=A1nek wrot= e: > > On Mon, May 10, 2021 at 12:19:05PM -0500, Varun Varada wrote: > > On Fri, 30 Apr 2021 at 02:59, Michal Such=C3=A1nek = wrote: > > > > > > On Thu, Apr 29, 2021 at 08:51:07PM -0500, Varun Varada wrote: > > > > On Wed, 28 Apr 2021 at 13:49, Michal Such=C3=A1nek wrote: > > > > > > > > > > On Wed, Apr 28, 2021 at 01:15:07PM -0500, Varun Varada wrote: > > > > > > On Wed, 28 Apr 2021 at 03:58, Michal Such=C3=A1nek 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 recogni= ze '(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 referr= ing to as well. > > > > > > > > > > > > > > > > > > > > In case you have some issue with the word 'jargon' Merriam-We= bster gives > > > > > > > this definition: > > > > > > > > > > > > > > 1: the technical terminology or characteristic idiom of a spe= cial activity or group > > > > > > > 2: obscure and often pretentious language marked by circumloc= utions 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', respectivel= y. > > > > > > > > > > > > This is not true, especially in technical contexts. "Affect" do= esn't > > > > > > mean "has a slight effect on", but simply "has an effect on". T= his > > > > > > suffices in most cases. In cases where one would like to highli= ght the > > > > > > overwhelming/awesome/debilitating/marked/strong effect that som= ething > > > > > > has, "impact" can be used. To say that every effect is overwhel= ming or > > > > > > strong is jargon. > > > > > > > > > > > > > > > > > > > > If you can pick out a few places where the use is specificall= y 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 one= s 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 th= e 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 affec= t" > > > > > > 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 bu= t > > > 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 i= t > > > > 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 ter= ms > > > > of the degree of the effect it will have. > > > > > > Which also means that the distinction between 'strong effect' and > > > 'effect' is meaningless, and 'affect' vs 'impact' is synonymous. > > > Replacing one with the other is useless churn then. > > > > I'm not sure I understand what you mean by "churn". No one would stop > > using Git because of these single-word changes. > > It refers to redundant changes to the codebase which do not improve it in > any way. I see. These changes remove the confusion about what the words mean, so they are not changes for the sake of changes. > > > > > As for there being no distinction, there's no gradation within the > > semantics of this context; this doesn't change the semantics of the > > words themselves. Using "impact" when what is meant is just "effect" > > or "affect" is incorrect in all such instances. > > That's your opinion not shared by the authors of the text. Are you referring to part about it changing the semantics of the words, or that it is incorrect to use them as such? Because neither of those are opinion; I've already cited sources that attest to this, and you've also agreed about the meaning of the words in question. Also, I'm getting the sense that you are one of the authors of the text being changed; am I correct in presuming this? > > The authority you refer to is MIT which is known for technical > brilliance but not as authority on linguistics. I also cited the Oxford English Dictionary and the Modern Language Association (MLA), arguably *the* authorities on the English language that are prevalent and popular for their guidance on usage. > > > > > > > > > Also the cases I saw do not really look confusing in any way so the > > > change does not improve the documentation in any way. > > > > Saying "will not impact" means "will not strongly affect", as you've > > already agreed. This necessarily means it might affect it, albeit not > > strongly. > > Or not at all. Sure. So, which is it? And how will the reader know which it is? This is my point. There's absolutely no reason to have this confusion. > > > This is confusing to anyone reading the documentation, and > > When the distinction is not meaningful it is not really confusing in > this use, either. > > > is entirely unnecessary. > > Also you did not limit your patch to these cases that you say are > confusing. > > > I don't understand the resistance here for > > simple one-word changes that remove this confusion. Am I missing > > something? > > There does not seem to be any confusion to remove, at least you have not > pointed out any specific case that is particularly confusing. I've pointed out that all of the negation examples are confusing because they are ambiguous. > > If you do wholesale word replacement in the project for no good reason > it only makes working with the project history harder. I'm not sure I understand the sentiment here. As in, the Git history will be polluted? Because the "git blame" command will only show changes for the lines where I changed the single words. And it reduces ambiguity in the command output, let alone the documentation; it is not pointless. If it wasn't confusing enough for a native English-speaking everyday user of Git, I wouldn't have taken the time to read through all of the documentation about how to submit patches to Git, followed all of the procedures, learned to work with some new Git commands, and actually made the changes to get all the way here just to make changes to the repository for the sake of it; I promise. > > Thanks > > Michal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You could make a case that 'impact' is significantly less fre= quent word > > > > > > > compared to effect/affect and thus makes the text harder to u= nderstand > > > > > > > for non-native speakers. However, that's not the point you br= ought up, > > > > > > > and even then it is very weak point to make, especially witho= ut any > > > > > > > actual source for the frequency data. You could also counter = that all of > > > > > > > these are common loanwords in many languages and are thus eas= y 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`, whi= ch is generated from > > > > > > > > `command-list.txt`. Find the line for 'git-pull' so you ca= n 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 aforementio= ned help > > > > > > > > commands. The > > > > > > > > +command which affects where it shows up in the aforementio= ned help > > > > > > > > commands. The > > > > > > > > top of `command-list.txt` shares some information about wh= at each attribute > > > > > > > > means; in those help pages, the commands are sorted accord= ing to these > > > > > > > > attributes. `git psuh` is user-facing, or porcelain - so w= e 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 shou= ld 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 obj= ects. > > > > > > > > +to yourself the runtime effect of tracking all omitted obj= ects. > > > > > > > > > > > > > > > > =3D=3D=3D 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 b= y not > > > > > > > > having to recompute the final delta result once the best = match > > > > > > > > for all objects is found. Repacking large repositories o= n machines > > > > > > > > - which are tight with memory might be badly impacted by th= is though, > > > > > > > > + which are tight with memory might be badly affected by th= is 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 c= an be > > > > > > > > allowed by providing this option on the command line. Th= is > > > > > > > > - 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 generati= ng the > > > > > > > > @@ -687,7 +687,7 @@ that contains SP the path must be quote= d. > > > > > > > > > > > > > > > > A `filecopy` command takes effect immediately. Once the s= ource > > > > > > > > location has been copied to the destination any future com= mands > > > > > > > > -applied to the source location will not impact the destina= tion of > > > > > > > > +applied to the source location will not affect the destina= tion of > > > > > > > > the copy. > > > > > > > > > > > > > > > > `filerename` > > > > > > > > @@ -708,7 +708,7 @@ that contains SP the path must be quote= d. > > > > > > > > A `filerename` command takes effect immediately. Once the= source > > > > > > > > location has been renamed to the destination any future co= mmands > > > > > > > > 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` follo= wed by a > > > > > > > > `filedelete` of the source location. There is a slight pe= rformance > > > > > > > > @@ -1010,7 +1010,7 @@ The `LF` after the command is optiona= l (it used > > > > > > > > to be required). > > > > > > > > ~~~~~~~~~~ > > > > > > > > Causes fast-import to print the entire `progress` line unm= odified to > > > > > > > > its standard output channel (file descriptor 1) when the c= ommand is > > > > > > > > -processed from the input stream. The command otherwise ha= s no impact > > > > > > > > +processed from the input stream. The command otherwise ha= s 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 m= ark to > > > > > > > > stdout or to the file descriptor previously arranged with = the > > > > > > > > -`--cat-blob-fd` argument. The command otherwise has no imp= act on the > > > > > > > > +`--cat-blob-fd` argument. The command otherwise has no eff= ect on the > > > > > > > > current import; its purpose is to retrieve SHA-1s that lat= er 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 pr= eviously > > > > > > > > arranged with the `--cat-blob-fd` argument. The command o= therwise > > > > > > > > -has no impact on the current import; its main purpose is t= o > > > > > > > > +has no effect on the current import; its main purpose is t= o > > > > > > > > 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 bounc= ing around > > > > > > > > -between branches has virtually no impact on import perform= ance. > > > > > > > > +between branches has virtually no effect on import perform= ance. > > > > > > > > > > > > > > > > Handling Renames > > > > > > > > ~~~~~~~~~~~~~~~~ > > > > > > > > diff --git a/Documentation/git-fetch.txt b/Documentation/gi= t-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 p= erformance > > > > > > > > worse on big and busy repos that have a lot of branch chur= n, and > > > > > > > > e.g. make the output of commands like `git branch -a --con= tains > > > > > > > > -` needlessly verbose, as well as impacting anythin= g else > > > > > > > > +` needlessly verbose, as well as affecting anythin= g else > > > > > > > > that'll work with the complete set of known references. > > > > > > > > > > > > > > > > These remote-tracking references can be deleted as a one-o= ff with > > > > > > > > diff --git a/Documentation/technical/hash-function-transiti= on.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 h= ash function > > > > > > > > could not be considered cryptographically secure any more.= This would > > > > > > > > -impact the communication of hash values because we could n= ot trust > > > > > > > > +affect the communication of hash values because we could n= ot 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, mak= e experimental > > > > > > > > changes and commit them, and you can discard any commits y= ou 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 c= reate, you may > > > > > > > > do so (now or later) by using -c with the switch command a= gain. 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 overwrit= ten by a > > > > > > > > half-merged results when this combining results in conflic= ts. > > > > > > > > Therefore, if you have uncommitted changes touching the sa= me 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 afterw= ards. > > > > > > > > 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, m= ake 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 t= o a branch.\n" > > > > > > > > + "state without affecting any branches by switching back t= o 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 c= har **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 allow= s 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 f= eature lines. > > > > > > > > + * command-line options that affect how we interpret the f= eature lines. > > > > > > > > */ > > > > > > > > for (i =3D 1; i < argc; i++) { > > > > > > > > const char *arg =3D 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 cause= s > > > > > > > > * 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 refa= ctorings 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-fetc= h-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-fo= llowing, but we never > > > > > > > > -actually grab them (and thus they will impact each subsequ= ent fetch). > > > > > > > > +actually grab them (and thus they will affect each subsequ= ent fetch). > > > > > > > > > > > > > > > > The child repository is a clone of parent, without the tag= s, and is at least > > > > > > > > one commit behind the parent (meaning that we will fetch o= ne 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 t= ree' '' ' > > > > > > > > # test standard ignores > > > > > > > > > > > > > > > > # First make sure that the presence of a file in the worki= ng 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-crede= ntial-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_SETU= P" || > > > > > > > > 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, ma= ke 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, ma= ke 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 i= t in a > > > > > > > > - # pseudo-ref to avoid impacting tests with --all. > > > > > > > > + # pseudo-ref to avoid affecting tests with --all. > > > > > > > > commit=3D$(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 t= est times away from a > > > > > > > > +# timezones affecting the result (as long as we keep our t= est times away from a > > > > > > > > # year boundary; our reference times are all in August). > > > > > > > > # > > > > > > > > # The output of tar_info is expected to be " "= , 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=3DBAR some-program", but run inside a subs= hell, which means > > > > > > > > -# it also works for shell functions (though those function= s cannot impact > > > > > > > > +# it also works for shell functions (though those function= s 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 wrote: > > > > > > > > > > > > > > > > > > On Tue, 6 Apr 2021 at 18:01, Jeff King wr= ote: > > > > > > > > > > > > > > > > > > > > On Tue, Apr 06, 2021 at 02:36:27PM -0500, Varun Varada = wrote: > > > > > > > > > > > > > > > > > > > > > > while using "will not impact" in an incorrect or un= clear 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 figurative= ly; 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 sig= nificant or > > > > > > > > > > > > > > > > > > > > It literally uses "affect" to define it. The "especiall= y 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" b= it and the > > > > > > > > > like being there in all the entries. I'm not sure about t= hese > > > > > > > > > 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 a= ffect me?" [syn: > > > > > > > > > > > > affect, impact, bear upon, bear on, touch = on, > > > > > > > > > > > > touch] > > > > > > > > > > > > > > > > > > > > That is likewise listing "impact" and "affect" as synon= yms. > > > > > > > > > > > > > > > > > > > > I do agree the word is over-used in some forms of writi= ng, 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 op= en 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 orig= inal writers > > > > > > > > > > intact unless there is a good reason not to. > > > > > > > > > > > > > > > > > > I am a native English speaker as well, and there were mul= tiple 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 perfec= tly good > > > > > > > > > alternative that doesn't have this confusion / jargon sta= tus, I wanted > > > > > > > > > to make the change to improve it, especially where it say= s that in the > > > > > > > > > output of the git command (`git checkout` when in detache= d 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_chec= k(mstate m); > > > > > > > > > > > #endif /* (FOOTERS && !INSECURE) */ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -/* In gcc, use __builtin_expect to minimize impact o= f checks */ > > > > > > > > > > > +/* In gcc, use __builtin_expect to minimize affect o= f checks */ > > > > > > > > > > > #if !INSECURE > > > > > > > > > > > #if defined(__GNUC__) && __GNUC__ >=3D 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 u= nnecessary > > > > > > > > > > conflicts when pulling in new versions). > > > > > > > > > > > > > > > > > > That's fair; I wasn't aware that this was being pulled di= rectly from > > > > > > > > > another project. I can change this back. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, this one should be "effect" anyway, as it is a no= un. > > > > > > > > > > > > > > > > > > This seems to have slipped through, as I used a text sear= ch tool. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Peff