All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Keene <seraphire@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>
Cc: Denton Liu <liu.denton@gmail.com>,
	Ben Keene via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH v3 1/4] git-p4: yes/no prompts should sanitize user text
Date: Mon, 16 Dec 2019 14:11:00 -0500	[thread overview]
Message-ID: <0ce91fe5-df41-b4de-6e74-036c346df577@gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1912152125390.46@tvgsbejvaqbjf.bet>


On 12/15/2019 3:30 PM, Johannes Schindelin wrote:
> Hi Junio,
>
> On Fri, 13 Dec 2019, Junio C Hamano wrote:
>
>> Denton Liu <liu.denton@gmail.com> writes:
>>
>>>> @@ -4170,3 +4175,4 @@ def main():
>>>>
>>>>   if __name__ == '__main__':
>>>>       main()
>>>> +
>>> Spurious trailing line. Perhaps we could make GGG error out on
>>> whitespace errors before submissions are allowed?
>> I think you are asking the tool for too much support.
>>
>> It may help a lot more if we gave a Makefile target (or two) that
>> the contributors can run before going public.  Perhaps
>>
>>
>> 	O=origin/master
>> 	upstream-check::
>> 		git log -p --check $(O)..
>>
>> that can be used like so:
>>
>> 	$ make upstream-check
>> 	$ make O=gitster/next upstream-check
>>
>> That way, those who use format-patch+email without GGG or those who
>> push to a shared repository to be reviewed among the peer developers
>> before going public would benefit, not just GGG users.
>>
>> Hmm?
> I'd like that a lot, _and_ I think GitGitGadget could learn the trick of
> running that `Makefile` target and report failures back to the PR
> _especially_ because GitGitGadget knows the base branch of the PR.
>
> In my opinion, there is a lot of value in having GitGitGadget doing this,
> as new contributors are likely to miss such a helpful `Makefile` target.
> For example, I vividly remember when I contributed to cURL for the first
> time and had totally and completely missed the invocation `make -C src
> checksrc` to help me get the code into the preferred shape.
>
> Ciao,
> Dscho

Same here for me.  My entry point into submissions was through GGG.  The
more suggestions it can offer prior to "/submit"ting code the easier it
would have been for me and the less noise I would have brought to the
mailing list.

- Ben


  parent reply	other threads:[~2019-12-16 19:11 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-09 14:16 [PATCH 0/3] git-p4: Usability enhancements Ben Keene via GitGitGadget
2019-12-09 14:16 ` [PATCH 1/3] git-p4: [usability] yes/no prompts should sanitize user text Ben Keene via GitGitGadget
2019-12-09 22:00   ` Junio C Hamano
2019-12-10 14:26     ` Ben Keene
2019-12-09 14:16 ` [PATCH 2/3] git-p4: [usability] RCS Keyword failure should suggest help Ben Keene via GitGitGadget
2019-12-09 22:22   ` Junio C Hamano
2019-12-09 14:16 ` [PATCH 3/3] git-p4: [usability] Show detailed help when parsing options fail Ben Keene via GitGitGadget
2019-12-09 22:24   ` Junio C Hamano
2019-12-09 22:06 ` [PATCH 0/3] git-p4: Usability enhancements Junio C Hamano
2019-12-10 15:22 ` [PATCH v2 0/4] " Ben Keene via GitGitGadget
2019-12-10 15:22   ` [PATCH v2 1/4] git-p4: yes/no prompts should sanitize user text Ben Keene via GitGitGadget
2019-12-11 11:52     ` Denton Liu
2019-12-11 11:59     ` Denton Liu
2019-12-10 15:22   ` [PATCH v2 2/4] git-p4: show detailed help when parsing options fail Ben Keene via GitGitGadget
2019-12-10 15:22   ` [PATCH v2 3/4] git-p4: wrap patchRCSKeywords test to revert changes on failure Ben Keene via GitGitGadget
2019-12-10 15:22   ` [PATCH v2 4/4] git-p4: failure because of RCS keywords should show help Ben Keene via GitGitGadget
2019-12-11 11:29     ` Denton Liu
2019-12-11  9:43   ` [PATCH v2 0/4] git-p4: Usability enhancements Luke Diamand
2019-12-12 19:46   ` [PATCH v3 " Ben Keene via GitGitGadget
2019-12-12 19:46     ` [PATCH v3 1/4] git-p4: yes/no prompts should sanitize user text Ben Keene via GitGitGadget
2019-12-13  1:45       ` Denton Liu
2019-12-13 13:42         ` Ben Keene
2019-12-13 19:46         ` Junio C Hamano
2019-12-15 20:30           ` Johannes Schindelin
2019-12-16 17:54             ` Junio C Hamano
2019-12-16 19:11             ` Ben Keene [this message]
2019-12-12 19:46     ` [PATCH v3 2/4] git-p4: show detailed help when parsing options fail Ben Keene via GitGitGadget
2019-12-12 19:46     ` [PATCH v3 3/4] git-p4: wrap patchRCSKeywords test to revert changes on failure Ben Keene via GitGitGadget
2019-12-12 19:46     ` [PATCH v3 4/4] git-p4: failure because of RCS keywords should show help Ben Keene via GitGitGadget
2019-12-13 13:57     ` [PATCH v4 0/4] git-p4: Usability enhancements Ben Keene via GitGitGadget
2019-12-13 13:57       ` [PATCH v4 1/4] git-p4: yes/no prompts should sanitize user text Ben Keene via GitGitGadget
2019-12-13 22:54         ` Denton Liu
2019-12-16 13:53           ` Ben Keene
2019-12-13 13:57       ` [PATCH v4 2/4] git-p4: show detailed help when parsing options fail Ben Keene via GitGitGadget
2019-12-13 13:58       ` [PATCH v4 3/4] git-p4: wrap patchRCSKeywords test to revert changes on failure Ben Keene via GitGitGadget
2019-12-13 13:58       ` [PATCH v4 4/4] git-p4: failure because of RCS keywords should show help Ben Keene via GitGitGadget
2019-12-16 14:02       ` [PATCH v5 0/4] git-p4: Usability enhancements Ben Keene via GitGitGadget
2019-12-16 14:02         ` [PATCH v5 1/4] git-p4: yes/no prompts should sanitize user text Ben Keene via GitGitGadget
2019-12-16 14:02         ` [PATCH v5 2/4] git-p4: show detailed help when parsing options fail Ben Keene via GitGitGadget
2019-12-16 14:02         ` [PATCH v5 3/4] git-p4: wrap patchRCSKeywords test to revert changes on failure Ben Keene via GitGitGadget
2019-12-16 14:02         ` [PATCH v5 4/4] git-p4: failure because of RCS keywords should show help Ben Keene via GitGitGadget
2019-12-16 20:39         ` [PATCH v5 0/4] git-p4: Usability enhancements Junio C Hamano
2019-12-21 10:19           ` Luke Diamand
2019-12-25 19:13             ` Junio C Hamano
2020-01-02 13:50               ` Ben Keene
2020-01-02 21:44                 ` Junio C Hamano

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=0ce91fe5-df41-b4de-6e74-036c346df577@gmail.com \
    --to=seraphire@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=liu.denton@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.