comment: Fix spelling mistakes inside comments

[skx]

This commit fixes a couple of minor spelling mistakes inside
comments.

Signed-off-by: Steve Kemp [email protected]

Thanks for taking the time to contribute to Git! Please be advised that the
Git community does not use github.com for their contributions. Instead, we use
a mailing list ([email protected]) for code submissions, code reviews, and
bug reports. Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/)
to conveniently send your Pull Requests commits to our mailing list.

Please read the "guidelines for contributing" linked above!

[gitgitgadget]

Welcome to GitGitGadget

Hi @skx, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.

Please make sure that your Pull Request has a good description, as it will be used as cover letter.

Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:

• the lines should not exceed 76 columns,
• the first line should be like a header and typically start with a prefix like "tests:" or "commit:", and
• the commit messages' body should be describing the "why?" of the change.
• Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.

It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.

Contributing the patches

Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form /allow. A good way to find other contributors is to locate recent pull requests where someone has been /allowed:

• Search: is:pr is:open "/allow"

Both the person who commented /allow and the PR author are able to /allow you.

An alternative is the channel #git-devel on the FreeNode IRC network:

<newcontributor> I've just created my first PR, could someone please /allow me? https://github.com/gitgitgadget/git/pull/12345
<veteran> newcontributor: it is done
<newcontributor> thanks!

Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.

If you want to see what email(s) would be sent for a /submit request, add a PR comment /preview to have the email(s) sent to you. You must have a public GitHub email address for this.

After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail).

If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the (raw) link), then import it into your mail program. If you use GMail, you can do this via:

curl -g --user "<EMailAddress>:<Password>" \
    --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

To iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description):

Changes since v1:
- Fixed a typo in the commit message (found by ...)
- Added a code comment to ... as suggested by ...
...

To send a new iteration, just add another PR comment with the contents: /submit.

Need help?

New contributors who want advice are encouraged to join [email protected], where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join.

You may also be able to find help in real time in the developer IRC channel, #git-devel on Freenode. Remember that IRC does not support offline messaging, so if you send someone a private message and log out, they cannot respond to you. The scrollback of #git-devel is archived, though.

[gitgitgadget]

There is an issue in commit 0b59791:
Prefixed commit message must be in lower case: comment: Fix spelling mistakes inside comments

[webstech]

/allow

[gitgitgadget]

User skx is now allowed to use GitGitGadget.

WARNING: skx has no public email address set on GitHub

[skx]

/preview

[gitgitgadget]

Preview email sent as [email protected]

[skx]

/submit

[gitgitgadget]

Submitted as [email protected]

[gitgitgadget]

On the Git mailing list, Derrick Stolee wrote (reply to this):

On 7/28/20 11:33 PM, Steve Kemp via GitGitGadget wrote:
> From: Steve Kemp <[email protected]>
> 
> This commit fixes a couple of minor spelling mistakes inside
> comments.
> 
> Signed-off-by: Steve Kemp <[email protected]>
> Signed-off-by: Steve Kemp <[email protected]>

Double sign-off? Perhaps keep the org.uk version, since that
is the email you use for authorship.

> -			/* abandonded */
> +			/* abandoned */

> -/* Print a cell to stdout with all necessary leading/traling space */
> +/* Print a cell to stdout with all necessary leading/trailing space */

> -		 * currenty thread-safe and might be racy with object reading,
> +		 * currently thread-safe and might be racy with object reading,

> - * 1. Only a single level of inderection is obtained, we might want to
> + * 1. Only a single level of indirection is obtained, we might want to

These edits are all positive ones.

I'll leave it to more experienced contributors to comment on how a
comment-only patch fits with this section Documentation/CodingGuidelines:

 - Fixing style violations while working on a real change as a
   preparatory clean-up step is good, but otherwise avoid useless code
   churn for the sake of conforming to the style.

In my opinion, this change is not harmful, but also isn't super
necessary. I could go either way.

Thanks,
-Stolee

[skx]

Double sign-off? Perhaps keep the org.uk version, since that
is the email you use for authorship.

Thanks for that, I've corrected now.

In my opinion, this change is not harmful, but also isn't super
necessary. I could go either way.

If it were a white-space change, or a some trivial style-guide fixup I'd
have left it alone. As it is the patch fixes a couple of mistakes, albeit
trivial ones, I thought it was worth submitting.

I'd be happy to see it merged, or dropped, whichever seems most
appropriate. I appreciate it is internal and not user-visible, but when
I read comments with typos in them they jump out!

Steve

[gitgitgadget]

On the Git mailing list, Steve Kemp wrote (reply to this):

On Wed, 29 Jul 2020 at 16:45, Derrick Stolee <[email protected]> wrote:

> Double sign-off? Perhaps keep the org.uk version, since that
> is the email you use for authorship.

Sorry, thanks.

> In my opinion, this change is not harmful, but also isn't super
> necessary. I could go either way.

If it were a white-space change, or a some trivial style-guide fixup
I'd have left it alone. As it is the patch fixes a couple of mistakes,
albeit trivial ones, I thought it was worth submitting.

I'd be happy to see it merged, or dropped, whichever seems most
appropriate. I appreciate it is internal and not user-visible, but
when I read comments with typos in them they jump out!

Updated patch, trivially, below.

Steve
-- 


From: Steve Kemp <[email protected]>

This commit fixes a couple of minor spelling mistakes inside
comments.

Signed-off-by: Steve Kemp <[email protected]>
---
    comment: Fix spelling mistakes inside comments

    This commit fixes a couple of minor spelling mistakes inside comments.

    Signed-off-by: Steve Kemp [email protected] [[email protected]]

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-685%2Fskx%2Fmaster-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-685/skx/master-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/685

 add-patch.c  | 2 +-
 column.c     | 2 +-
 grep.c       | 2 +-
 ref-filter.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/add-patch.c b/add-patch.c
index f899389e2c..a1d66c1b75 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1203,7 +1203,7 @@ static int edit_hunk_loop(struct add_p_state *s,
  for (;;) {
  int res = edit_hunk_manually(s, hunk);
  if (res == 0) {
- /* abandonded */
+ /* abandoned */
  *hunk = backup;
  return -1;
  }
diff --git a/column.c b/column.c
index 4a38eed322..a58969baba 100644
--- a/column.c
+++ b/column.c
@@ -107,7 +107,7 @@ static void display_plain(const struct string_list *list,
  printf("%s%s%s", indent, list->items[i].string, nl);
 }

-/* Print a cell to stdout with all necessary leading/traling space */
+/* Print a cell to stdout with all necessary leading/trailing space */
 static int display_cell(struct column_data *data, int initial_width,
  const char *empty_cell, int x, int y)
 {
diff --git a/grep.c b/grep.c
index 13232a904a..54af9f813e 100644
--- a/grep.c
+++ b/grep.c
@@ -1817,7 +1817,7 @@ static int grep_source_1(struct grep_opt *opt,
struct grep_source *gs, int colle
  * We might set up the shared textconv cache data here, which
  * is not thread-safe. Also, get_oid_with_context() and
  * parse_object() might be internally called. As they are not
- * currenty thread-safe and might be racy with object reading,
+ * currently thread-safe and might be racy with object reading,
  * obj_read_lock() must be called.
  */
  grep_attr_lock();
diff --git a/ref-filter.c b/ref-filter.c
index 8447cb09be..f836f3830c 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1980,7 +1980,7 @@ static int for_each_fullref_in_pattern(struct
ref_filter *filter,
  * of oids. If the given ref is a tag, check if the given tag points
  * at one of the oids in the given oid array.
  * NEEDSWORK:
- * 1. Only a single level of inderection is obtained, we might want to
+ * 1. Only a single level of indirection is obtained, we might want to
  * change this to account for multiple levels (e.g. annotated tags
  * pointing to annotated tags pointing to a commit.)
  * 2. As the refs are cached we might know what refname peels to without

base-commit: 47ae905ffb98cc4d4fd90083da6bc8dab55d9ecc
-- 
gitgitgadget

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

Derrick Stolee <[email protected]> writes:

> I'll leave it to more experienced contributors to comment on how a
> comment-only patch fits with this section Documentation/CodingGuidelines:
>
>  - Fixing style violations while working on a real change as a
>    preparatory clean-up step is good, but otherwise avoid useless code
>    churn for the sake of conforming to the style.
>
> In my opinion, this change is not harmful, but also isn't super
> necessary. I could go either way.

Typofixes in comments has no chance of breaking things than a
carelessly done code churn made in the name of cleaning up, so
cost-benefit comparison is much more favourable.  I'm sure that I
won't be exhausted after reviewing comment-only patch as much as
after reviewing code-churn only patch.

[gitgitgadget]

On the Git mailing list, Derrick Stolee wrote (reply to this):

On 7/29/2020 2:16 PM, Junio C Hamano wrote:
> Derrick Stolee <[email protected]> writes:
> 
>> I'll leave it to more experienced contributors to comment on how a
>> comment-only patch fits with this section Documentation/CodingGuidelines:
>>
>>  - Fixing style violations while working on a real change as a
>>    preparatory clean-up step is good, but otherwise avoid useless code
>>    churn for the sake of conforming to the style.
>>
>> In my opinion, this change is not harmful, but also isn't super
>> necessary. I could go either way.
> 
> Typofixes in comments has no chance of breaking things than a
> carelessly done code churn made in the name of cleaning up, so
> cost-benefit comparison is much more favourable.  I'm sure that I
> won't be exhausted after reviewing comment-only patch as much as
> after reviewing code-churn only patch.

Thanks. I appreciate the context that provides more clarity.

Steve's patch with the de-duplicated sign-off has my full support.

-Stolee

[gitgitgadget]

This branch is now known as sk/typofixes.

[gitgitgadget]

This patch series was integrated into seen via git@538bb82.

[gitgitgadget]

This patch series was integrated into seen via git@5df3f2a.

[gitgitgadget]

This patch series was integrated into seen via git@a13cd59.

[gitgitgadget]

This patch series was integrated into next via git@c56d9e5.

[gitgitgadget]

This patch series was integrated into seen via git@8a111fc.

[gitgitgadget]

This patch series was integrated into next via git@8a111fc.

[gitgitgadget]

This patch series was integrated into master via git@8a111fc.

[gitgitgadget]

Closed via 8a111fc.