Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Matt Hunter" <m@lfurio.us>
Cc: <git@vger.kernel.org>
Subject: Re: [PATCH 4/6] MyFirstContribution: clarify that 'seen' does not mean acceptance
Date: Sun, 12 Jul 2026 12:04:43 -0700	[thread overview]
Message-ID: <xmqqqzl82fn8.fsf@gitster.g> (raw)
In-Reply-To: <DJWSKKVJM03B.1DTV8F9FXG9IF@lfurio.us> (Matt Hunter's message of "Sun, 12 Jul 2026 14:08:02 -0400")

"Matt Hunter" <m@lfurio.us> writes:

> On Sat Jul 11, 2026 at 3:26 PM EDT, Junio C Hamano wrote:
>> +
>> +Plenty of early testers use `next` and
>>  may report issues. Eventually, changes in `next` will make it to `master`,
>>  which is typically considered stable. Finally, when a new release is cut,
>>  `maint` is used to base bugfixes onto. As mentioned at the beginning of this
>
> It feels odd not to reflow this paragraph, where the first line now just
> stops halfway across the width of the paragraph.  Though, the diff-churn
> may not be worth it in your eyes.

Yes, I did not want to force patch readers to review three extra
lines just to spot a non-existent difference caused by an
unnecessary reflow.  Unlike SubmittingPatches, the target audience
for MyFirstContribution is less familiar with our source files than
experienced contributors are, so they will not be reading this in
its source form anyway.  Therefore, I thought leaving an unusually
short line there was a reasonable trade-off until the entire
paragraph needs to be rewritten.

However, when the next person who wants to modify this source file
reads it, it will indeed be distracting to them.  So, perhaps I
should reflow the remainder of the paragraph.

Thanks.

  reply	other threads:[~2026-07-12 19:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-11 19:26 [PATCH 0/6] Update Contributor Guides Junio C Hamano
2026-07-11 19:26 ` [PATCH 1/6] SubmittingPatches: clarify expected structure of commit log message Junio C Hamano
2026-07-12 14:49   ` Weijie Yuan
2026-07-12 16:07     ` Junio C Hamano
2026-07-13 14:14       ` Weijie Yuan
2026-07-12 20:26   ` Michael Montalbo
2026-07-13  0:07     ` Junio C Hamano
2026-07-13 14:14       ` Weijie Yuan
2026-07-11 19:26 ` [PATCH 2/6] MyFirstContribution: what if I don't get a reply? Junio C Hamano
2026-07-11 19:26 ` [PATCH 3/6] MyFirstContribution: carrying over trailers Junio C Hamano
2026-07-11 19:26 ` [PATCH 4/6] MyFirstContribution: clarify that 'seen' does not mean acceptance Junio C Hamano
2026-07-12 18:08   ` Matt Hunter
2026-07-12 19:04     ` Junio C Hamano [this message]
2026-07-11 19:26 ` [PATCH 5/6] SubmittingPatches: clarify the meaning of "Will queue" Junio C Hamano
2026-07-11 19:26 ` [PATCH 6/6] SubmittingPatches: clarify the writing style of whats-cooking Junio C Hamano
2026-07-12 20:41   ` Michael Montalbo
2026-07-13  4:20     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqqzl82fn8.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=m@lfurio.us \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox