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

Re: What's cooking in git.git (topics)

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 6, 2008, 09:31 UTC
Message-ID
<7v8x1y1leg.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<m3zluf4s6r.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
Show 17 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * jc/submittingpatches (Sun Feb 3 17:02:28 2008 -0800) 3 commits
>>  + Documentation/SubmittingPatches: What's Acked-by and Tested-by?
>>  + Documentation/SubmittingPatches: discuss first then submit
>>  + Documentation/SubmittingPatches: Instruct how to use [PATCH]
>>    Subject header
>> 
>> These I think are sensible but they did not see much discussion,
>> so they are parked here for now.
>
> In those series I think the middle patch could be improved. I guess
> that need for brevity overcame need for being explicit. I don't know
> if patches meant for discussion are to be send to mailing list only,
> or if the patches meant for submissions are to be sent to git mailing
> list _and_ maintainer (and is it an error to send them only to the
> list) from this description.

Yeah, I was very unsure about the wording. What I think is the ideal patch flow is:

 (0) You come up with an itch.  You code it up.
 (1) Send it to the list and cc people who may need to know about
     the change.
     The people who may need to know are the ones whose code you
     are butchering.  These people happen to be the ones who are
     most likely to be knowledgeable enough to help you, but
     they have no obligation to help you (i.e. you ask for help,
     don't demand).
     The people could include me, but that is not because I am
     currently the maintainer, but because I may happen to have
     been involved in the code you are touching.
 (2) You get comments and suggestions for improvements.  You may
     even get them in a "on top of" patch form.
 (3) Polish, refine, and re-send to the list and the people who
     spend their time to improve your patch.  Go back to step (2).
 (4) The list forms consensus that the last round of your patch is
     good.  Send it to the list and cc me.
 (5) It is merged to 'next', and cooked further and eventually
     graduates to 'master'.

In any time between the (2)-(3) cycle, I should pick it up from the list and queue it to 'pu', in order to make it easier for people play with it without having to pick up and apply the patch to their trees themselves.

Previous: Jakub NarebskiNext: Junio C Hamano
Message 5 of 50 in “What's cooking in git.git (topics)”
  1. Junio C HamanoFeb 3, 2008
  2. Johannes SchindelinFeb 3, 2008
  3. Junio C HamanoFeb 5, 2008
  4. Jakub NarebskiFeb 5, 2008
  5. Junio C HamanoFeb 6, 2008
  6. Junio C HamanoFeb 7, 2008
  7. Jeff KingFeb 7, 2008
  8. Lars HjemliFeb 7, 2008
  9. Jakub NarebskiFeb 7, 2008
  10. Junio C HamanoFeb 10, 2008
  11. Jakub NarebskiFeb 10, 2008
  12. Johannes SchindelinFeb 10, 2008
  13. Junio C HamanoFeb 10, 2008
  14. Junio C HamanoFeb 10, 2008
  15. Junio C HamanoFeb 12, 2008
  16. reflog-delete, was Re: What's cooking in git.git (topics)Johannes Schindelin, Feb 12, 2008
  17. Junio C HamanoFeb 17, 2008
  18. Jeff KingFeb 17, 2008
  19. Jakub NarebskiFeb 17, 2008
  20. Junio C HamanoFeb 17, 2008
  21. Jakub NarebskiFeb 17, 2008
  22. Junio C HamanoFeb 18, 2008
  23. Jakub NarebskiFeb 18, 2008
  24. Matthias KestenholzFeb 17, 2008
  25. Junio C HamanoFeb 17, 2008
  26. Jeff KingFeb 17, 2008
  27. [Announce] 'next' rewound and rebasedJunio C Hamano, Feb 17, 2008
  28. Junio C HamanoFeb 21, 2008
  29. Johannes SchindelinFeb 21, 2008
  30. Junio C HamanoFeb 21, 2008
  31. Brandon CaseyFeb 22, 2008
  32. 1/4 git-reflog: add option --rewrite to update reflog entries while expiringBrandon Casey, Feb 22, 2008
  33. reflog-delete: parse standard reflog optionsBrandon Casey, Feb 22, 2008
  34. Junio C HamanoFeb 22, 2008
  35. Brandon CaseyFeb 23, 2008
  36. Junio C HamanoFeb 23, 2008
  37. Junio C HamanoFeb 23, 2008
  38. Brandon CaseyFeb 23, 2008
  39. Junio C HamanoFeb 25, 2008
  40. Junio C HamanoFeb 28, 2008
  41. Junio C HamanoMar 1, 2008
  42. Shawn O. PearceMar 2, 2008
  43. Junio C HamanoMar 3, 2008
  44. Junio C HamanoMar 6, 2008
  45. Johannes SchindelinMar 6, 2008
  46. Junio C HamanoMar 8, 2008
  47. 2/4 refs.c: make close_ref() and commit_ref() non-staticBrandon Casey, Feb 22, 2008
  48. 3/4 git-reflog: add option --updateref to write the last reflog sha1 into the refBrandon Casey, Feb 22, 2008
  49. 4/4 git-stash: add new 'drop' subcommandBrandon Casey, Feb 22, 2008
  50. git-stash: add new 'pop' subcommandBrandon Casey, Feb 22, 2008

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.