git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
To: Stefan Beller <sbeller@google.com>, Junio C Hamano <gitster@pobox.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged
Date: Mon, 07 Aug 2017 20:04:50 +0530	[thread overview]
Message-ID: <1502116490.3172.6.camel@gmail.com> (raw)
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.

> 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

  reply	other threads:[~2017-08-07 14:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-30 11:09 [PATCH 1/2] doc: fix small issues in SubmittingPatches Kaartic Sivaraam
2017-07-30 11:09 ` [PATCH 2/2] doc: add another way to identify if a patch has been merged Kaartic Sivaraam
2017-07-30 14:49 ` [PATCH 1/2] doc: fix small issues in SubmittingPatches Philip Oakley
2017-07-30 16:17   ` Kaartic Sivaraam
2017-07-30 16:18   ` Kaartic Sivaraam
2017-07-31 20:23     ` Stefan Beller
2017-07-31 20:34       ` Junio C Hamano
2017-08-01 15:59       ` Kaartic Sivaraam
2017-08-01 17:38         ` Stefan Beller
2017-08-02 12:22           ` [RFC] The correct and consistent alternative to quote a command ? Kaartic Sivaraam
2017-08-02 15:37             ` Junio C Hamano
2017-08-02 17:32             ` Stefan Beller
2017-08-03 15:35               ` Kaartic Sivaraam
2017-08-01 16:05       ` [PATCH 1/2] doc: fix small issues in SubmittingPatches Kaartic Sivaraam
2017-08-01 16:05         ` [PATCH 2/2] doc: add another way to identify if a patch has been merged Kaartic Sivaraam
2017-08-01 17:46           ` Stefan Beller
2017-08-02 12:32             ` Kaartic Sivaraam
2017-08-02 16:01               ` Junio C Hamano
2017-08-02 16:28                 ` Junio C Hamano
2017-08-02 17:58                   ` Stefan Beller
2017-08-07 14:34                     ` Kaartic Sivaraam [this message]
2017-08-07 14:33                 ` Kaartic Sivaraam
2017-08-01 21:04       ` [PATCH 1/2] doc: fix small issues in SubmittingPatches Philip Oakley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1502116490.3172.6.camel@gmail.com \
    --to=kaarticsivaraam91196@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).