git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 1/4] git-p4: yes/no prompts should sanitize user text

From
Ben Keene <seraphire@gmail.com>
Date
Dec 16, 2019, 19:11 UTC
Message-ID
<0ce91fe5-df41-b4de-6e74-036c346df577@gmail.com>
In-Reply-To
<nycvar.QRO.7.76.6.1912152125390.46@tvgsbejvaqbjf.bet>
On 12/15/2019 3:30 PM, Johannes Schindelin wrote:
Show 45 quoted lines
> 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
Previous: Junio C HamanoNext: Ben Keene via GitGitGadget
Message 29 of 46 in “git-p4: Usability enhancements”
  1. 0/3 git-p4: Usability enhancementsBen Keene via GitGitGadget, Dec 9, 2019
  2. 1/3 git-p4: [usability] yes/no prompts should sanitize user textBen Keene via GitGitGadget, Dec 9, 2019
  3. Junio C HamanoDec 9, 2019
  4. Ben KeeneDec 10, 2019
  5. 2/3 git-p4: [usability] RCS Keyword failure should suggest helpBen Keene via GitGitGadget, Dec 9, 2019
  6. Junio C HamanoDec 9, 2019
  7. 3/3 git-p4: [usability] Show detailed help when parsing options failBen Keene via GitGitGadget, Dec 9, 2019
  8. Junio C HamanoDec 9, 2019
  9. Junio C HamanoDec 9, 2019
  10. 0/4 git-p4: Usability enhancementsBen Keene via GitGitGadget, Dec 10, 2019
  11. 2/4 git-p4: show detailed help when parsing options failBen Keene via GitGitGadget, Dec 10, 2019
  12. 4/4 git-p4: failure because of RCS keywords should show helpBen Keene via GitGitGadget, Dec 10, 2019
  13. Denton LiuDec 11, 2019
  14. 3/4 git-p4: wrap patchRCSKeywords test to revert changes on failureBen Keene via GitGitGadget, Dec 10, 2019
  15. 1/4 git-p4: yes/no prompts should sanitize user textBen Keene via GitGitGadget, Dec 10, 2019
  16. Denton LiuDec 11, 2019
  17. Denton LiuDec 11, 2019
  18. Luke DiamandDec 11, 2019
  19. 0/4 git-p4: Usability enhancementsBen Keene via GitGitGadget, Dec 12, 2019
  20. 2/4 git-p4: show detailed help when parsing options failBen Keene via GitGitGadget, Dec 12, 2019
  21. 3/4 git-p4: wrap patchRCSKeywords test to revert changes on failureBen Keene via GitGitGadget, Dec 12, 2019
  22. 4/4 git-p4: failure because of RCS keywords should show helpBen Keene via GitGitGadget, Dec 12, 2019
  23. 1/4 git-p4: yes/no prompts should sanitize user textBen Keene via GitGitGadget, Dec 12, 2019
  24. Denton LiuDec 13, 2019
  25. Ben KeeneDec 13, 2019
  26. Junio C HamanoDec 13, 2019
  27. Johannes SchindelinDec 15, 2019
  28. Junio C HamanoDec 16, 2019
  29. Ben KeeneDec 16, 2019
  30. 0/4 git-p4: Usability enhancementsBen Keene via GitGitGadget, Dec 13, 2019
  31. 2/4 git-p4: show detailed help when parsing options failBen Keene via GitGitGadget, Dec 13, 2019
  32. 3/4 git-p4: wrap patchRCSKeywords test to revert changes on failureBen Keene via GitGitGadget, Dec 13, 2019
  33. 1/4 git-p4: yes/no prompts should sanitize user textBen Keene via GitGitGadget, Dec 13, 2019
  34. Denton LiuDec 13, 2019
  35. Ben KeeneDec 16, 2019
  36. 4/4 git-p4: failure because of RCS keywords should show helpBen Keene via GitGitGadget, Dec 13, 2019
  37. 0/4 git-p4: Usability enhancementsBen Keene via GitGitGadget, Dec 16, 2019
  38. 1/4 git-p4: yes/no prompts should sanitize user textBen Keene via GitGitGadget, Dec 16, 2019
  39. 4/4 git-p4: failure because of RCS keywords should show helpBen Keene via GitGitGadget, Dec 16, 2019
  40. 3/4 git-p4: wrap patchRCSKeywords test to revert changes on failureBen Keene via GitGitGadget, Dec 16, 2019
  41. 2/4 git-p4: show detailed help when parsing options failBen Keene via GitGitGadget, Dec 16, 2019
  42. Junio C HamanoDec 16, 2019
  43. Luke DiamandDec 21, 2019
  44. Junio C HamanoDec 25, 2019
  45. Ben KeeneJan 2, 2020
  46. Junio C HamanoJan 2, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.