Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged

From: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
Date: Aug 7, 2017, 14:34 UTC
Message-ID: <1502116490.3172.6.camel@gmail.com>
In-Reply-To: <CAGZ79kYArf6R-vx1-Lm4X_ANLMrXc3VNd2aCQMnqq3J6y-s31Q@mail.gmail.com>

On Wed, 2017-08-02 at 10:58 -0700, Stefan Beller wrote:

>     That may be either a contributors problem (lacking time or
>     motivation to go through a long document) or a problem with
>     the community.
>

I'm trying to avoid the former.

Show 10 quoted lines

> I would not want to explain the same thing over and over again,
> but rather have a technical solution that explains the problem and
> solution once it is detected.
> 
> Coming up with a technical solution for each little quirk
> is not the hard part (e.g. grep for the sign off string, count lines of
> the commit message), but rather to put it in place. (How can I make
> sure that contributors run these small checker scripts?
> Currently I cannot.)
>

I could see quite some alternatives for this.

1. scripts

    I guess the kernel community use some scripts to check if the patch
    has the required style.[ref 1][ref 2]. I guess we could do something
    similar. Like writing a script that checks the log messages for the
    required format (sign-off, area etc.) and giving users advice about
    how to fix the issue. After a all script test pass we could give
    some advice to the user about how the patch needs to be sent.

    To identify the set of commit messages that need to be checked we
    could make the script accept a single parameter that specifies the
    base of the branch. I'm not sure if this part could be automated.

2. Hooks

    warning: this might be a little over thought.

    1. Code all the checks as 'hooks scripts' that aren't samples.
    Possibly scripts related to 'commit-msg'.

    2. Place them in a 'hooks' directory under a new directory, possibly
    named 'hook-checks'.

    3. Inform the new contributor to re-initialize his git.git with

            $ git init --template=/path/to/git/hook-checks

    4. Rebasing their commits with 'rewording' each

    Of course, this relies on the fact that he wouldn't have enabled
    hooks in their git.git. In which case he would have to merge the
    scripts with his own scripts.

I'm not pretty sure if they're feasible or not.

-- 
Kaartic