Unfill-paragraph when converting commit messages to PR descriptions

[xmo-odoo]

Conventionally, commit messages should be fill-paragraph'd to 72 characters (except the first line which should be limited to 50).

However when Github picks that up to generate a garbage-looking PR message since GFM interprets line breaks as line breaks but double breaks as paragraphs.

This is made worse by the visual expansion and contraction of references e.g. a #-reference to an issue or PR gets expanded with the entire title of the corresponding object, but a 40 characters hash reference gets shortened to 7~8. Links and footnotes in markdown-style also get altered by the transition.

If github "unfilled" the paragraphs of text (removed the linebreaks but kept the paragraph breaks) it'd make PRs much better looking out of the box for people who write & format extensive commit messages.

[brasic]

@xmo-odoo would you be interested in beta testing this feature?

Edit: this is shipped!

[jstasiak]

Hey @brasic thank you for working on this. The issue is resolved in many cases but I still see it reappear every now and then. The latest one I just got, this commit message

Do something

1. Grab the aaaaaaaaa aaaaa database overview file[1][2][3].
   Size: 12345678
   SHA256 sum: 1231231231231231231231231231231231231231231231231231231231231231
2. Extract the "asdasdasdasd" sheet.

gets converted to this PR description (the title is Do something as expected)

1. Grab the aaaaaaaaa aaaaa database overview file[1][2][3]. Size: 12345678 SHA256 sum: 1231231231231231231231231231231231231231231231231231231231231231
2. Extract the "asdasdasdasd" sheet.

[jstasiak]

@brasic another example of a broken PR description

Commit message:

Bla bla bla

The actual response type looks like this:

    interface MapiResponse<T = any> {
        /**
         * The response body, parsed as JSON.
         */
        body: T;
        /**
         * The raw response body.
         */
        rawBody: string;
        /**
         * The response's status code.
         */
        statusCode: number;
        /**
         * The parsed response headers.
         */
        headers: any;
        /**
         * The parsed response links
         */
        links: any;
        /**
         * The response's originating MapiRequest.
         */
        request: MapiRequest<T>;
        hasNextPage(): boolean;
        nextPage(): MapiRequest<T> | null;
    }

the PR description generated from the above:

The actual response type looks like this:

    interface MapiResponse<T = any> {
        /**
         * The response body, parsed as JSON. */ body: T; /**
         * The raw response body. */ rawBody: string; /** * The response's status code. */ statusCode: number; /** * The parsed response headers. */ headers: any; /** * The parsed response links */ links: any; /** * The response's originating MapiRequest. */ request: MapiRequest<T>; hasNextPage(): boolean; nextPage(): MapiRequest<T> | null; }

Needless to say it's a problem.

[jstasiak]

@brasic another random case

Commit message

Something something

As a bonus this allows us to remove some potentially unsafe type
assertions.
    
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#string_coercion
[2] One exception would be if toString() did something other than we
    wanted, but this is not the case here.

PR description generated from the above:

As a bonus this allows us to remove some potentially unsafe type assertions.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#string_coercion [2] One exception would be if toString() did something other than we
    wanted, but this is not the case here.

This is really annoying.

Can this behavior be completely disabled or at least a switch introduced to disabled it for a given GH user?

[jstasiak]

@brasic The issues described above are still live. Is there a timeline for when this problem is resolved? It's a really disruptive bug that the PR descriptions are mangled like this.

[brasic]

I don't work at GitHub anymore.