Re: [GSoC][PATCH v2 1/5] t0000-basic: fix an indentation error

From: Christian Couder <christian.couder@gmail.com>
Date: Mar 15, 2019, 12:48 UTC
Message-ID: <CAP8UFD09QZd=6HyB5Om1PfV=67+CvfyQkcpLU0tukT48QccD0Q@mail.gmail.com>
In-Reply-To: <CAOAu_YLTft7xmx4xvoM5Qqe0CHjqWrH+DUysHq0zfSEU8vodkg@mail.gmail.com>

Hi,

On Fri, Mar 15, 2019 at 2:55 AM jonathan chang <ttjtftx@gmail.com> wrote:

>
> On Mon, Mar 11, 2019 at 1:59 AM Thomas Gummerer <t.gummerer@gmail.com> wrote:
> >
> > On 03/10, Jonathan Chang wrote:

Show 10 quoted lines

> > > Also I found that there is no such function as test_char_count,
> > > is it worthwile to add such function? Here are some stat:
> > >
> > > `git grep 'test_line_count' | wc -l` = 626
> > > `git grep 'wc -l' | wc -l` = 294
> > > `git grep 'wc -c' | wc -l` = 68
> >
> > I do think it would be helpful to introduce that helper, especially if
> > it is useful in this patch series.  There seem to be enough other
> > places where it can be useful to make it worth adding the helper.

Yeah, it would be useful for Git, but it's not necessary of course for your microproject, which is already more than big enough.

Show 8 quoted lines

> > > This is a preparatory step prior to removing the pipes after git
> > > commands, which discards git's exit code and may mask a crash.
> >
> > The commit message should also describe why we need this preparatory
> > step. Maybe something like:
> >
> >       To reduce the noise in when refactoring this pipeline in a
> >       subsequent commit fix the indentation.

Or perhaps:

      Fix indentation of a line containing a pipeline to reduce the
noise when refactoring the pipeline in a subsequent commit.

Show 5 quoted lines

> This has been wrong
> >       since the refactoring done in 1b5b2b641a ("t0000: modernise
> >       style", 2012-03-02), but carries no meaning.
> >
> > > Signed-off-by: Jonathan Chang <ttjtftx@gmail.com>

Show 11 quoted lines

> > Since this patch series is now 5 patches, that commentary should go
> > into a cover letter (see the --cover-letter option in format-patch),
> > so the reviewers can read that first, and read the patches with that
> > in mind, focusing on the patch only, and not additional commentary
> > that applies to the whole series when reading the patch.
>
> I wasn't aware of this option. I tried to produce the format in others
> cover letter using 'git diff' and options like '--stat', '--summary', with no
> success. I consulted Documentation/SubmittingPatches, where I got the
> idea of cover letter, but it doesn't mention the option '--cover-letter' and
> the idea of cover letter is even confused with '--notes'[1].

The issue is that there are different things that can be considered "cover letter". I agree that it's not very clear in Documentation/SubmittingPatches.

There is the following which is related to --cover-letter:

"Multiple related patches should be grouped into their own e-mail thread to help readers find all parts of the series. To that end, send them as replies to either an additional "cover letter" message (see below), the first patch, or the respective preceding patch."

but it doesn't mention --cover-letter and it contains "(see below)" though I don't see what that refers to.

> I just reread some of the GSoC related mails in the mailing list and
> found one[2] that introduced the usage of 'cover-letter', '--range-diff' and
> '--interdiff'. As a newbie, I personally think it would be helpful to include
> theses options along with others mentioned in SubmittingPatches.

I agree that there is room for improvement in SubmittingPatches.

Thanks, Christian.