git/Documentation/MyFirstContribution.txt, branch v2.37.2

MyFirstContribution: drop PR description for GGG single-patch contributions

2022-05-13T01:10:00Z

By default, GitHub prefills the PR description using the commit message for single-commit PRs. This results in a duplicate commit message below the three-dash line if the contributor does not empty out the PR description before submitting, which adds noise for reviewers. Add a note to that effect in MyFirstContribution.txt. This partly addresses: https://github.com/gitgitgadget/gitgitgadget/issues/340 Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano

MyFirstContribution: reference "The cover letter" in GitGitGadget section

2022-05-13T01:10:00Z

The "Sending Patches via GitGitGadget" section mentions that the PR title and description will be used as the cover letter, but does not explain what is a cover letter or what should be included in it. Refer readers to the new "The cover letter" section added in a previous commit. Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano

MyFirstContribution: reference "The cover letter" in "Preparing Email"

2022-05-13T01:09:59Z

The previous commit added a standalone section on the purpose of the cover letter, drawing inspiration from the existing content of the "Preparing Email" section. Adjust "Preparing Email" to reference "The cover letter", to avoid content duplication. Also, use the imperative mode for the cover letter subject, as is done in "The cover letter". Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano

MyFirstContribution: add standalone section on cover letter

2022-05-13T01:09:59Z

An explanation of the purpose of the cover letter is included in the "Sending Patches with git send-email" / "Preparing Email" section but is missing from the "Sending Patches via GitGitGadget" section. Add a standalone section "The cover letter" under the "Getting Started: Anatomy of a Patch Series" header to explain what the cover letter is used for and to draft the cover letter of the 'psuh' topic used in the tutorial. For now we mostly copy content from the "Sending Patches with git send-email" section but do not adjust that section, nor the GGG section, to reference the new section. This is done in following commits. Also, adjust the "Preparing Email" Asciidoc anchor to avoid conflicts. Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano

MyFirstContribution: add "Anatomy of a Patch Series" section

2022-05-13T01:09:59Z

Before describing how to send patches to the mailing list either with GitGitGadget or 'git send-email', the MyFirstContribution tutorial includes a small "Getting Ready to Share" section where the two different methods are briefly introduced. Use this section to also describe what a patch series looks like once submitted, so that readers get an understanding of the end result before diving into how to accomplish that end result. Start by copying the "thread overview" section of a recent contribution from the public-inbox web UI and explaining how each commit is a separate mail, and point out the cover letter. Subsequent commits will move the existing description of the purpose of the cover letter from the 'git send-email' section to this "anatomy" section. Also, change the wording in the introductory paragraph to use "contributions" instead of "patches", since this makes more sense when talking about GitHub pull requests. Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano

Merge branch 'jc/tutorial-format-patch-base'

2021-11-29T23:41:46Z

Teach and encourage first-time contributors to this project to state the base commit when they submit their topic. * jc/tutorial-format-patch-base: MyFirstContribution: teach to use "format-patch --base=auto"

MyFirstContribution: teach to use "format-patch --base=auto"

2021-10-23T21:03:11Z

Let's encourage first-time contributors to tell us what commit they based their work on with the format-patch invocation. As the example already forks from origin/master and branch.autosetupmerge by default records the upstream when the psuh branch was created, we can use --base=auto for this. Also, mention that the range of commits can simply be given with `@{u}` if they are on the `psuh` branch already. As we are getting one more option on the command line, and spending one paragraph each to explain them, let's reformat that part of the description as a bulleted list. Helped-by: Bagas Sanjaya Signed-off-by: Junio C Hamano

MyFirstContribution: Document --range-diff option when writing v2

2021-09-22T21:25:05Z

In the "Sending v2" section, readers are directed to create v2 patches without using --range-diff. However, it is customary to include a range-diff against the v1 patches as a reviewer aid. Update the "Sending v2" section to suggest a simple workflow that uses the --range-diff option. Also include some explanation for -v2 and --range-diff to help the reader understand the importance. Signed-off-by: Glen Choo Signed-off-by: Junio C Hamano

MyFirstContribution: link #git-devel to Libera Chat

2021-06-09T00:22:54Z

Many of the regulars on #git-devel are now on Libera Chat, to the extent that the community page now lists it as the IRC Channel[1]. This will help new contributors find the right place, if they choose to ask questions on `#git-devel`. Relevant discussion on the IRC transition: https://lore.kernel.org/git/CAJoAoZ=e62sceNpcR5L5zjsj177uczTnXjcAg+BbOoOkeH8vXQ@mail.gmail.com/ [1] https://git-scm.com/community Signed-off-by: Atharva Raykar Reviewed-by: Emily Shaffer Signed-off-by: Junio C Hamano

tests: remove support for GIT_TEST_GETTEXT_POISON

2021-01-21T23:50:01Z

This removes the ability to inject "poison" gettext() messages via the GIT_TEST_GETTEXT_POISON special test setup. I initially added this as a compile-time option in bb946bba761 (i18n: add GETTEXT_POISON to simulate unfriendly translator, 2011-02-22), and most recently modified to be toggleable at runtime in 6cdccfce1e0 (i18n: make GETTEXT_POISON a runtime option, 2018-11-08).. The reason for its removal is that the trade-off of maintaining it v.s. what it's getting us has long since flipped. When gettext was integrated in 5e9637c6297 (i18n: add infrastructure for translating Git with gettext, 2011-11-18) there was understandable concern on the Git ML that in marking messages for translation en-masse we'd inadvertently mark plumbing messages. The GETTEXT_POISON facility was a way to smoke those out via our test suite. Nowadays however we're done (or almost entirely done) with any marking of messages for translation. New messages are usually marked by their authors, who'll know whether it makes sense to translate them or not. If not any errors in marking the messages are much more likely to be spotted in review than in the the initial deluge of i18n patches in the 2011-2012 era. So let's just remove this. This leaves the test suite in a state where we still have a lot of test_i18n, C_LOCALE_OUTPUT etc. uses. Subsequent commits will remove those too. The change to t/lib-rebase.sh is a selective revert of the relevant part of f2d17068fd (i18n: rebase-interactive: mark comments of squash for translation, 2016-06-17), and the comment in t/t3406-rebase-message.sh is from c7108bf9ed (i18n: rebase: mark messages for translation, 2012-07-25). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano