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.
> 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
