{"thread":{"id":"62174","subject":"[PATCH v2 1/2] Documentation/config: fix typos","startedAt":"2024-09-23T11:03:59Z","lastAt":"2024-11-25T20:21:20Z","messageCount":9,"participants":["Andrew Kreimer","Eric Sunshine","Kristoffer Haugsbakk"],"isPatch":true,"patchVersion":2,"patchTotal":2},"messages":[{"id":"503247","messageId":"20240923110343.12388-1-algonell@gmail.com","threadId":"62174","inReplyTo":null,"subject":"[PATCH v2 1/2] Documentation/config: fix typos","fromName":"Andrew Kreimer","fromEmail":"algonell@gmail.com","sentAt":"2024-09-23T11:03:42Z","receivedAt":"2024-09-23T11:03:59Z","isPatch":true,"sender":{"key":"algonell@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4669001?v=4"},"body":"Fix typos in documentation.\n\nSigned-off-by: Andrew Kreimer \n---\n Documentation/config/extensions.txt | 2 +-\n Documentation/config/gc.txt | 2 +-\n Documentation/config/remote.txt | 2 +-\n 3 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/config/extensions.txt b/Documentation/config/extensions.txt\nindex 38dce3df35..f0a784447d 100644\n--- a/Documentation/config/extensions.txt\n+++ b/Documentation/config/extensions.txt\n@@ -9,7 +9,7 @@ work and will produce hard-to-diagnose issues.\n \n extensions.compatObjectFormat::\n \n-\tSpecify a compatitbility hash algorithm to use. The acceptable values\n+\tSpecify a compatibility hash algorithm to use. The acceptable values\n \tare `sha1` and `sha256`. The value specified must be different from the\n \tvalue of extensions.objectFormat. This allows client level\n \tinteroperability between git repositories whose objectFormat matches\ndiff --git a/Documentation/config/gc.txt b/Documentation/config/gc.txt\nindex 1d4f9470ea..21d56db279 100644\n--- a/Documentation/config/gc.txt\n+++ b/Documentation/config/gc.txt\n@@ -163,7 +163,7 @@ gc.repackFilterTo::\n \tcontaining the filtered out objects. **WARNING:** The\n \tspecified location should be accessible, using for example the\n \tGit alternates mechanism, otherwise the repo could be\n-\tconsidered corrupt by Git as it migh not be able to access the\n+\tconsidered corrupt by Git as it might not be able to access the\n \tobjects in that packfile. See the `--filter-to=` option\n \tof linkgit:git-repack[1] and the `objects/info/alternates`\n \tsection of linkgit:gitrepository-layout[5].\ndiff --git a/Documentation/config/remote.txt b/Documentation/config/remote.txt\nindex 36e771556c..71d1fee835 100644\n--- a/Documentation/config/remote.txt\n+++ b/Documentation/config/remote.txt\n@@ -50,7 +50,7 @@ remote..skipFetchAll::\n \tIf true, this remote will be skipped when updating\n \tusing linkgit:git-fetch[1], the `update` subcommand of\n \tlinkgit:git-remote[1], and ignored by the prefetch task\n-\tof `git maitenance`.\n+\tof `git maintenance`.\n \n remote..receivepack::\n \tThe default program to execute on the remote side when pushing. See\n-- \n2.39.5\n\n"},{"id":"503248","messageId":"20240923110343.12388-2-algonell@gmail.com","threadId":"62174","inReplyTo":"20240923110343.12388-1-algonell@gmail.com","subject":"[PATCH v2 2/2] Documentation: fix typos","fromName":"Andrew Kreimer","fromEmail":"algonell@gmail.com","sentAt":"2024-09-23T11:03:43Z","receivedAt":"2024-09-23T11:04:00Z","isPatch":true,"sender":{"key":"algonell@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4669001?v=4"},"body":"Fix typos in documentation.\n\nSigned-off-by: Andrew Kreimer \n---\n Documentation/BreakingChanges.txt | 2 +-\n Documentation/DecisionMaking.txt | 2 +-\n Documentation/gitformat-commit-graph.txt | 2 +-\n Documentation/gitweb.txt | 2 +-\n 4 files changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/BreakingChanges.txt b/Documentation/BreakingChanges.txt\nindex 2b64665694..112770a9da 100644\n--- a/Documentation/BreakingChanges.txt\n+++ b/Documentation/BreakingChanges.txt\n@@ -117,7 +117,7 @@ Cf. <20140304174806.GA11561@sigill.intra.peff.net>.\n \n * The git-pack-redundant(1) command can be used to remove redundant pack files.\n The subcommand is unusably slow and the reason why nobody reports it as a\n- performance bug is suspected to be the absense of users. We have nominated\n+ performance bug is suspected to be the absence of users. We have nominated\n the command for removal and have started to emit a user-visible warning in\n c3b58472be (pack-redundant: gauge the usage before proposing its removal,\n 2020-08-25) whenever the command is executed.\ndiff --git a/Documentation/DecisionMaking.txt b/Documentation/DecisionMaking.txt\nindex dbb4c1f569..b43c472ae5 100644\n--- a/Documentation/DecisionMaking.txt\n+++ b/Documentation/DecisionMaking.txt\n@@ -54,7 +54,7 @@ implementation, for very large changes).\n \n For non-technical decisions such as community norms or processes, it is up to\n the community as a whole to implement and sustain agreed-upon changes.\n-The project leadership committe (PLC) may help the implementation of\n+The project leadership committee (PLC) may help the implementation of\n policy decisions.\n \n \ndiff --git a/Documentation/gitformat-commit-graph.txt b/Documentation/gitformat-commit-graph.txt\nindex 3e906e8030..14d1631234 100644\n--- a/Documentation/gitformat-commit-graph.txt\n+++ b/Documentation/gitformat-commit-graph.txt\n@@ -122,7 +122,7 @@ All multi-byte numbers are in network byte order.\n for commits with corrected commit date offsets that cannot be\n stored within 31 bits.\n * Generation Data Overflow chunk is present only when Generation Data\n- chunk is present and atleast one corrected commit date offset cannot\n+ chunk is present and at least one corrected commit date offset cannot\n be stored within 31 bits.\n \n ==== Extra Edge List (ID: {'E', 'D', 'G', 'E'}) [Optional]\ndiff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt\nindex 56d24a30a3..5e2b491ec2 100644\n--- a/Documentation/gitweb.txt\n+++ b/Documentation/gitweb.txt\n@@ -234,7 +234,7 @@ from the template during repository creation, usually installed in\n configuration variable, but the file takes precedence.\n \n category (or `gitweb.category`)::\n-\tSinge line category of a project, used to group projects if\n+\tSingle line category of a project, used to group projects if\n \t`$projects_list_group_categories` is enabled. By default (file and\n \tconfiguration variable absent), uncategorized projects are put in the\n \t`$project_list_default_category` category. You can use the\n-- \n2.39.5\n\n"},{"id":"503271","messageId":"CAPig+cSZmKCwy_sFKPR-w+DjXeTJJec1BAM6wDXMyEMWhoAY6g@mail.gmail.com","threadId":"62174","inReplyTo":"20240923110343.12388-1-algonell@gmail.com","subject":"Re: [PATCH v2 1/2] Documentation/config: fix typos","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-09-23T17:51:50Z","receivedAt":"2024-09-23T17:52:02Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Sep 23, 2024 at 7:04 AM Andrew Kreimer wrote:\n> Fix typos in documentation.\n>\n> Signed-off-by: Andrew Kreimer \n\nThanks. The changes in v2 of this series look fine.\n\nIn the future, to make life easier for reviewers, when rerolling a\npatch series, please include a cover letter (\"git format-patch\n--cover-letter\") and include the following in the cover letter:\n\n* explain in your own words how the new version of the series differs\nfrom the previous version\n\n* provide a link to the cover-letter of the previous version (i.e.\nhttps://lore.kernel.org/git/20240920082815.8192-1-algonell@gmail.com/)\n\n* include a range-diff (\"git format-patch --range-diff=\") which\nprovides a mechanical representation of the differences between the\nnew version of the series and the previous version\n\nDepending upon how dramatically the patch series changes from one\nversion to the next, the range-diff may end up being unreadable\ngobbledygook, in which case you may instead want to include an\ninterdiff (\"git format-patch --interdiff\").\n\nIf you're rerolling just a single patch instead of a full patch\nseries, rather than including a cover letter, instead place the above\ninformation in the commentary section of the patch (immediately below\nthe \"---\" line which follows your sign-off), and use \"git format-patch\n--range-diff\" (or \"--interdiff\") to insert the mechanical differences\n(which may appear in the commentary section or at the end of the\npatch, depending upon which version of Git you're using).\n"},{"id":"503272","messageId":"CAPig+cR5BdfVRwdXJ7viJbvgkUW7KStG2Y_=qGNzoXWrOgZcJg@mail.gmail.com","threadId":"62174","inReplyTo":"CAPig+cSZmKCwy_sFKPR-w+DjXeTJJec1BAM6wDXMyEMWhoAY6g@mail.gmail.com","subject":"Re: [PATCH v2 1/2] Documentation/config: fix typos","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-09-23T17:59:16Z","receivedAt":"2024-09-23T17:59:28Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Sep 23, 2024 at 1:51 PM Eric Sunshine wrote:\n> Thanks. The changes in v2 of this series look fine.\n>\n> In the future, to make life easier for reviewers, when rerolling a\n> patch series, please include a cover letter (\"git format-patch\n> --cover-letter\") and include the following in the cover letter:\n>\n> * explain in your own words how the new version of the series differs\n> from the previous version\n>\n> * provide a link to the cover-letter of the previous version (i.e.\n> https://lore.kernel.org/git/20240920082815.8192-1-algonell@gmail.com/)\n>\n> * include a range-diff (\"git format-patch --range-diff=\") which\n> provides a mechanical representation of the differences between the\n> new version of the series and the previous version\n\nI forgot to mention email threading as a way to further help reviewers\nand readers of the mailing list archive...\n\nWhen sending a reroll of a series, use \"git send-email --reply-to=\" to\nreference the cover letter of the previous version. If your email\nclient doesn't provide an easy way to access the ID of the previous\ncover letter, you can grab it from the list archive. For instance,\nconsulting the above link:\n\n git send-email --reply-to='20240920082815.8192-1-algonell@gmail.com' ...\n"},{"id":"503274","messageId":"85ed3ec6-fa4e-4ab8-872f-6bd500b2bb66@app.fastmail.com","threadId":"62174","inReplyTo":"CAPig+cSZmKCwy_sFKPR-w+DjXeTJJec1BAM6wDXMyEMWhoAY6g@mail.gmail.com","subject":"Re: [PATCH v2 1/2] Documentation/config: fix typos","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2024-09-23T18:43:39Z","receivedAt":"2024-09-23T18:44:01Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"Hi\n\nOn Mon, Sep 23, 2024, at 19:51, Eric Sunshine wrote:\n> Depending upon how dramatically the patch series changes from one\n> version to the next, the range-diff may end up being unreadable\n> gobbledygook, in which case you may instead want to include an\n> interdiff (\"git format-patch --interdiff\").\n\nWhat’s the benefit of interdiff in that case? Neither\ngit-format-patch(1) nor git-range-diff(1) seems to discuss what the\ndifferences between these two are.\n\n-- \nKristoffer Haugsbakk\n"},{"id":"503279","messageId":"CAPig+cSErj4ZB9bHB8mZfzNkiaN_EpjT6b4b=cfsf_+KMqytiA@mail.gmail.com","threadId":"62174","inReplyTo":"85ed3ec6-fa4e-4ab8-872f-6bd500b2bb66@app.fastmail.com","subject":"Re: [PATCH v2 1/2] Documentation/config: fix typos","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-09-23T19:05:54Z","receivedAt":"2024-09-23T19:06:06Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Sep 23, 2024 at 2:44 PM Kristoffer Haugsbakk\n wrote:\n> On Mon, Sep 23, 2024, at 19:51, Eric Sunshine wrote:\n> > Depending upon how dramatically the patch series changes from one\n> > version to the next, the range-diff may end up being unreadable\n> > gobbledygook, in which case you may instead want to include an\n> > interdiff (\"git format-patch --interdiff\").\n>\n> What’s the benefit of interdiff in that case? Neither\n> git-format-patch(1) nor git-range-diff(1) seems to discuss what the\n> differences between these two are.\n\nAn interdiff is just a plain diff. If you have branch (or tag) \"v1\"\nwhich is the original version of a patch series, and \"v2\" which is the\nreroll of the series, then interdiff is simply:\n\n git diff v1 v2\n\nThus, it shows the difference between the final state of the code at\nv1 and the state at v2. Interdiffs are easy to read because they are\njust diffs. However, because they are only showing differences in file\ncontent, they don't show changes to commit messages or new or removed\nor reordered patches in a series.\n\nA range-diff is a diff-of-diffs. It is very, very roughly similar to this:\n\n git format-patch -o v1-patches ..v1\n git format-patch -o v2-patches ..v2\n some-diff-dir-command v1-patches v2-patches\n\nIt shows the diff of the patches themselves, including changes to\ncommit messages and changes to changes, as well as inserted and\nremoved and reordered patches.\n\nRange-diffs tend to be a good deal more difficult to read (at least at\nfirst) but help show the evolution of the _patch series_ itself\nbetween versions, whereas interdiffs show only the evolution of the\n_code_ between versions. As a reviewer, if you're primarily interested\nin how the code evolved, then interdiffs are much more easily\ndigested, but most reviewers are also interested in the holistic\naspects of a patch series for which range-diffs are more helpful. I\nperiodically include both range-diff and interdiffs in my rerolls.\n"},{"id":"503281","messageId":"7944f06f-33d9-4988-85ab-c1cf563615f3@app.fastmail.com","threadId":"62174","inReplyTo":"CAPig+cSErj4ZB9bHB8mZfzNkiaN_EpjT6b4b=cfsf_+KMqytiA@mail.gmail.com","subject":"Re: [PATCH v2 1/2] Documentation/config: fix typos","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2024-09-23T19:13:25Z","receivedAt":"2024-09-23T19:13:46Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Mon, Sep 23, 2024, at 21:05, Eric Sunshine wrote:\n> On Mon, Sep 23, 2024 at 2:44 PM Kristoffer Haugsbakk\n> wrote:\n>> On Mon, Sep 23, 2024, at 19:51, Eric Sunshine wrote:\n>> > Depending upon how dramatically the patch series changes from one\n>> > version to the next, the range-diff may end up being unreadable\n>> > gobbledygook, in which case you may instead want to include an\n>> > interdiff (\"git format-patch --interdiff\").\n>>\n>> What’s the benefit of interdiff in that case? Neither\n>> git-format-patch(1) nor git-range-diff(1) seems to discuss what the\n>> differences between these two are.\n>\n> An interdiff is just a plain diff. If you have branch (or tag) \"v1\"\n> which is the original version of a patch series, and \"v2\" which is the\n> reroll of the series, then interdiff is simply:\n>\n> git diff v1 v2\n>\n> Thus, it shows the difference between the final state of the code at\n> v1 and the state at v2. Interdiffs are easy to read because they are\n> just diffs. However, because they are only showing differences in file\n> content, they don't show changes to commit messages or new or removed\n> or reordered patches in a series.\n>\n> A range-diff is a diff-of-diffs. It is very, very roughly similar to this:\n>\n> git format-patch -o v1-patches ..v1\n> git format-patch -o v2-patches ..v2\n> some-diff-dir-command v1-patches v2-patches\n>\n> It shows the diff of the patches themselves, including changes to\n> commit messages and changes to changes, as well as inserted and\n> removed and reordered patches.\n>\n> Range-diffs tend to be a good deal more difficult to read (at least at\n> first) but help show the evolution of the _patch series_ itself\n> between versions, whereas interdiffs show only the evolution of the\n> _code_ between versions. As a reviewer, if you're primarily interested\n> in how the code evolved, then interdiffs are much more easily\n> digested, but most reviewers are also interested in the holistic\n> aspects of a patch series for which range-diffs are more helpful. I\n> periodically include both range-diff and interdiffs in my rerolls.\n\nThanks for that. I love when a good range-diff falls out of a\nreroll—and I love the tool—but of course that can’t be expected out of\nevery reroll.\n\n-- \nKristoffer Haugsbakk\n\n"},{"id":"503286","messageId":"ZvHJD73k_SETqAsu@void.void","threadId":"62174","inReplyTo":"CAPig+cR5BdfVRwdXJ7viJbvgkUW7KStG2Y_=qGNzoXWrOgZcJg@mail.gmail.com","subject":"Re: [PATCH v2 1/2] Documentation/config: fix typos","fromName":"Andrew Kreimer","fromEmail":"algonell@gmail.com","sentAt":"2024-09-23T20:01:19Z","receivedAt":"2024-09-23T20:01:24Z","isPatch":true,"sender":{"key":"algonell@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4669001?v=4"},"body":"On Mon, Sep 23, 2024 at 01:59:16PM -0400, Eric Sunshine wrote:\n> On Mon, Sep 23, 2024 at 1:51 PM Eric Sunshine wrote:\n> > Thanks. The changes in v2 of this series look fine.\n> >\n> > In the future, to make life easier for reviewers, when rerolling a\n> > patch series, please include a cover letter (\"git format-patch\n> > --cover-letter\") and include the following in the cover letter:\n> >\n> > * explain in your own words how the new version of the series differs\n> > from the previous version\n> >\n> > * provide a link to the cover-letter of the previous version (i.e.\n> > https://lore.kernel.org/git/20240920082815.8192-1-algonell@gmail.com/)\n> >\n> > * include a range-diff (\"git format-patch --range-diff=\") which\n> > provides a mechanical representation of the differences between the\n> > new version of the series and the previous version\n> \n> I forgot to mention email threading as a way to further help reviewers\n> and readers of the mailing list archive...\n> \n> When sending a reroll of a series, use \"git send-email --reply-to=\" to\n> reference the cover letter of the previous version. If your email\n> client doesn't provide an easy way to access the ID of the previous\n> cover letter, you can grab it from the list archive. For instance,\n> consulting the above link:\n> \n> git send-email --reply-to='20240920082815.8192-1-algonell@gmail.com' ...\n\nAll noted, thank you!\n"},{"id":"508115","messageId":"9ab524df-bfe0-4c9a-a5e0-d07b955dbfe6@app.fastmail.com","threadId":"62174","inReplyTo":"7944f06f-33d9-4988-85ab-c1cf563615f3@app.fastmail.com","subject":"Re: [PATCH v2 1/2] Documentation/config: fix typos","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2024-11-25T20:20:57Z","receivedAt":"2024-11-25T20:21:20Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Mon, Sep 23, 2024, at 21:13, Kristoffer Haugsbakk wrote:\n> On Mon, Sep 23, 2024, at 21:05, Eric Sunshine wrote:\n>> [...]\n>>\n>> An interdiff is just a plain diff. If you have branch (or tag) \"v1\"\n>> which is the original version of a patch series, and \"v2\" which is the\n>> reroll of the series, then interdiff is simply:\n>>\n>> git diff v1 v2\n>>\n>> Thus, it shows the difference between the final state of the code at\n>> v1 and the state at v2. Interdiffs are easy to read because they are\n>> just diffs. However, because they are only showing differences in file\n>> content, they don't show changes to commit messages or new or removed\n>> or reordered patches in a series.\n>>\n>> A range-diff is a diff-of-diffs. It is very, very roughly similar to this:\n>>\n>> git format-patch -o v1-patches ..v1\n>> git format-patch -o v2-patches ..v2\n>> some-diff-dir-command v1-patches v2-patches\n>>\n>> It shows the diff of the patches themselves, including changes to\n>> commit messages and changes to changes, as well as inserted and\n>> removed and reordered patches.\n>>\n>> Range-diffs tend to be a good deal more difficult to read (at least at\n>> first) but help show the evolution of the _patch series_ itself\n>> between versions, whereas interdiffs show only the evolution of the\n>> _code_ between versions. As a reviewer, if you're primarily interested\n>> in how the code evolved, then interdiffs are much more easily\n>> digested, but most reviewers are also interested in the holistic\n>> aspects of a patch series for which range-diffs are more helpful. I\n>> periodically include both range-diff and interdiffs in my rerolls.\n>\n> Thanks for that. I love when a good range-diff falls out of a\n> reroll—and I love the tool—but of course that can’t be expected out of\n> every reroll.\n\nI guess I shouldn’t be surprised. But interdiff turned out to be really\nuseful. Minor rerolls are really easy to read. Such a pleasure to get\na quick sanity check before sending out a new round.\n\nAnd then I also get to use range-diff at the same time—the cherry on top.\n\n-- \nKristoffer Haugsbakk\n"}]}