GSoC - Code Formatting and Style Checking for RTEMS score

Gedare Bloom gedare at rtems.org
Thu Jul 1 16:30:53 UTC 2021


Hi Ida,

On Tue, Jun 29, 2021 at 1:11 PM Ida Delphine <idadelm at gmail.com> wrote:
>
> Hello mentors,
>
> Here is the code for my pre-commit hook script. How it works is by default, upon commiting it outputs a warning stating the number of style issues in case there are mismatches.
> The user can trigger the strict mode which gives a more detailed output of the style issues by running adding the mode to the config file ( git config mode "strict") - will document this.
>
> https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit
>
I made comments on your commit that added this:
https://github.com/Idadelveloper/rtems/commit/6bfc4802d17b3aab260190d53467b750848f0002

> I had already sent some screenshots here on how the outcome looks like. Will love to improve my code based on your feedback and get more suggestions.
>
>
> On Mon, Jun 21, 2021 at 7:05 PM Gedare Bloom <gedare at rtems.org> wrote:
>>
>>
>>
>> On Sun, Jun 20, 2021 at 1:13 AM Ida Delphine <idadelm at gmail.com> wrote:
>>>
>>> Hello everyone,
>>> I updated the hooks script. About the modes, we have the default, "strict" and "nonstrict" (couldn't think of better names). With the default mode, it prints a warning specifying the number of style issues if any and aborts the commit. With the strict mode, it goes into more detail showing both the formatted and unformatted patch, the number of style issues, and aborts the commit. In the non-strict mode, it simply displays the warning with the style issues and the commit happens.
>>>
>>> The default mode basically happens when you run
>>>>
>>>> git commit -m "Commit message"
>>>
>>> The best method I could find to pass arguments to a script was via environment variables. So the nonstrict mode applies when you run
>>>>
>>>> STYLEMODE=nonstrict git commit -m "Commit message"
>>>
>>> The strict mode applies when you run
>>>>
>>>> STYLEMODE=strict git commit -m "Commit message"
>>>
>>>
>> What are the possible options to pass arguments? (Maybe, a blog post :)) Reading from a git-config file would be better than environment variables.
>>
>> It might be better to share screenshots by a link (e.g., a blog post :)) to avoid hitting the mailing list attachment limits.
>>
>> Gedare


More information about the devel mailing list