Re: [PATCH 3/3] notes: don't indent empty lines

Eric Sunshine [off-list ref] writes:

The trailing whitespace is unusual within the Git sphere, as well as
unsightly if you happen to have your editor configured to highlight
trailing whitespace, and just "feels" sloppy.

But we are discussing this in the context of format-patch output,
where patches that change lines near a blank line will have a line
with a single SP on it in common context ;-)

I do not feel very strongly either way, though.

[1]: I suppose mechanical extraction of notes may be one such
scenario, allowing for simple-minded (not necessarily robust)
extraction mechanics; i.e. start extracting after the /^Notes:$/ line
and stop at the first line not indented with four blanks.

Yup, that was what I had in mind.

On Mon, Aug 30, 2021 at 1:56 PM Junio C Hamano [off-list ref] wrote:

Eric Sunshine [off-list ref] writes:

quoted

[1]: I suppose mechanical extraction of notes may be one such
scenario, allowing for simple-minded (not necessarily robust)
extraction mechanics; i.e. start extracting after the /^Notes:$/ line
and stop at the first line not indented with four blanks.

Yup, that was what I had in mind.

In the general case, such an extraction mechanism would be far too
fragile since there are no guarantees that the commentary in the
"Notes:" section hasn't been hand-edited after patch-generation.
However, it's certainly possible that such a simple-minded extraction
technique might be applicable in some well-controlled development
pipeline somewhere.

If we are worried about that, then we can drop this patch series.

On Mon, Aug 30, 2021 at 2:04 PM Eric Sunshine [off-list ref] wrote:

In the general case, such an extraction mechanism would be far too
fragile since there are no guarantees that the commentary in the
"Notes:" section hasn't been hand-edited after patch-generation.
However, it's certainly possible that such a simple-minded extraction
technique might be applicable in some well-controlled development
pipeline somewhere.

If we are worried about that, then we can drop this patch series.

Have we made a decision about whether this patch series -- which
avoids indenting blank notes lines -- is desirable? Or are we worried
about backward-compatibility? If we think there is value in this
series, then I can re-roll with Ævar suggestions. If not, perhaps I
can re-submit just patch [1/3] which makes a few tests less brittle.
Or, since those brittle tests aren't necessarily hurting anything, we
can just let this series die.

Thoughts?

On Fri, Sep 10, 2021 at 1:18 AM Eric Sunshine [off-list ref] wrote:

Have we made a decision about whether this patch series -- which
avoids indenting blank notes lines -- is desirable? Or are we worried
about backward-compatibility? If we think there is value in this
series, then I can re-roll with Ævar suggestions. If not, perhaps I
can re-submit just patch [1/3] which makes a few tests less brittle.
Or, since those brittle tests aren't necessarily hurting anything, we
can just let this series die.

I meant [2/3], not [1/3], as a possibility for a standalone
re-submission. That's the patch in which a few tests in t3303 and
t9301 which care only whether notes are present (or not) are made less
brittle by removing dependence upon the default output format of
git-log.