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

Re: Re: [PATCH v7] builtin/clone.c: add --reject-shallow option

From
Llilinchao@oschina.cn <lilinchao@oschina.cn>
Date
Mar 26, 2021, 03:34 UTC
Message-ID
<33a250a28de411eb9ccd0024e87935e7@oschina.cn>
In-Reply-To
<19c9dc128da911ebacc7d4ae5278bc1233465@pobox.com>

-------------- lilinchao@oschina.cn

Show 71 quoted lines
>"Li Linchao via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> ...
>> This patch offers a new option '--reject-shallow' that can reject to
>> clone a shallow repository.
>>
>> Signed-off-by: lilinchao <lilinchao@oschina.cn>
>>
>> Reviewed-by: Derrick Stolee <dstolee@microsoft.com>
>> Reviewed-by: Junio C Hamano<gitster@pobox.com>
>> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>> Reviewed-by: Jonathan Tan<jonathantanmy@google.com>
>
>The Reviewed-by trailer means something quite different from what
>you seem to think here.  It is only given by the reviewers to the
>patch when they carefully reviewed and agrees what is in the patch.
>The patch authors are in no position to add it, unless they are
>explicitly told by reviewers that "this patch now can have my
>Reviewed-by:" or some equivalent.
>
>The (ideal) flow of events is
>
> 0. The author comes up with an idea and writes a patch.
>
> 1. The patch is sent to the list and Cc'ed to people who may be
>    familiar with the area the patch touches.  For second and
>    subsequent iterations, those who gave review comments to the
>    previous iterations are also good people to Cc to.
>
> 2. People give comments as reponses to the patch.
>
>    (a) some may be happy with the iteration of the patch they
>        reviewed, and may say "Thanks for contributing, this is now
>        Reviewed-by: me".  For second and subsequent iterations,
>        they may say "This was improved relative to the previous
>        iteration, and it still looks good and you have my
>        Reviewed-by:".
>
>    (b) some may give constructive criticism, alternatives,
>        enhancements, or outright "not a good idea, don't do this
>        because ...".
>
>    (c) some may just act as cheerleaders.
>
> 3. The author thinks about the review comments and also may find
>    improvement him/herself.
>
>    (a) There may need an update to the patch.  If the patch has
>        changed since the previous version in any way, ignore
>        Reviewed-by: received in 2-(a).  When a significant help was
>        given to update the patch, you may add "Helped-by:" trailer
>        to credit the person's contribution.
>
>        Your own "Signed-off-by:" appears the last in the trailers
>        (i.e. "this iteration of the patch was written with help
>        from these people, and then I am signing it off just before
>        sending it out").
>
>	Go back to 1. and repeat as many times as it takes.
>   
>    (b) There may not be a need for any update to the patch.  Only
>        add the Reviewed-by: received in 2-(a) and otherwise do not
>        change anything.  Your own "Signed-off-by:" appears the last
>        in the trailers.  Send it to the list and to the maintainer
>        (me).
>
> 4. The maintainer applies the patch, unless there is no other
>    comments received on that supposedly-the-final version sent in
>    3-(b), but a late review comment may make us realize that it was
>    premature, in which case we may go back to 3-(a).
> 

Many thanks for so detailed instructions about work flow in git community. I will follow this flow tightly.

Previous: lilinchao@oschina.cnNext: lilinchao@oschina.cn
Message 46 of 48 in “builtin/clone.c: add --no-shallow option”
  1. builtin/clone.c: add --no-shallow optionLi Linchao via GitGitGadget, Feb 4, 2021
  2. Junio C HamanoFeb 4, 2021
  3. lilinchao@oschina.cnFeb 4, 2021
  4. Junio C HamanoFeb 4, 2021
  5. Johannes SchindelinFeb 4, 2021
  6. Junio C HamanoFeb 4, 2021
  7. 0/2 builtin/clone.c: add --no-shallow optionLi Linchao via GitGitGadget, Feb 8, 2021
  8. 1/2 builtin/clone.c: add --no-shallow optionlilinchao via GitGitGadget, Feb 8, 2021
  9. 2/2 builtin/clone.c: add --reject-shallow optionlilinchao via GitGitGadget, Feb 8, 2021
  10. Derrick StoleeFeb 8, 2021
  11. builtin/clone.c: add --reject-shallow optionLi Linchao via GitGitGadget, Feb 8, 2021
  12. Junio C HamanoFeb 9, 2021
  13. builtin/clone.c: add --reject-shallow optionLi Linchao via GitGitGadget, Feb 21, 2021
  14. Junio C HamanoFeb 22, 2021
  15. Jonathan TanMar 1, 2021
  16. Junio C HamanoMar 1, 2021
  17. lilinchao@oschina.cnMar 2, 2021
  18. Junio C HamanoMar 3, 2021
  19. Jonathan TanMar 4, 2021
  20. builtin/clone.c: add --reject-shallow optionLi Linchao via GitGitGadget, Feb 28, 2021
  21. lilinchao@oschina.cnMar 1, 2021
  22. Johannes SchindelinMar 1, 2021
  23. lilinchao@oschina.cnMar 4, 2021
  24. Junio C HamanoMar 3, 2021
  25. lilinchao@oschina.cnMar 4, 2021
  26. builtin/clone.c: add --reject-shallow optionLi Linchao via GitGitGadget, Mar 4, 2021
  27. lilinchao@oschina.cnMar 12, 2021
  28. builtin/clone.c: add --reject-shallow optionLi Linchao via GitGitGadget, Mar 25, 2021
  29. Junio C HamanoMar 25, 2021
  30. Junio C HamanoMar 25, 2021
  31. builtin/clone.c: add --reject-shallow optionLi Linchao via GitGitGadget, Mar 29, 2021
  32. Junio C HamanoMar 29, 2021
  33. Johannes SchindelinMar 30, 2021
  34. Junio C HamanoMar 30, 2021
  35. Johannes SchindelinMar 31, 2021
  36. builtin/clone.c: add --reject-shallow optionlilinchao via GitGitGadget, Mar 31, 2021
  37. Junio C HamanoMar 31, 2021
  38. Johannes SchindelinMar 31, 2021
  39. Junio C HamanoMar 31, 2021
  40. builtin/clone.c: add --reject-shallow optionLi Linchao via GitGitGadget, Apr 1, 2021
  41. lilinchao@oschina.cnFeb 8, 2021
  42. lilinchao@oschina.cnFeb 10, 2021
  43. Junio C HamanoFeb 10, 2021
  44. lilinchao@oschina.cnFeb 20, 2021
  45. lilinchao@oschina.cnFeb 28, 2021
  46. lilinchao@oschina.cnMar 26, 2021
  47. lilinchao@oschina.cnMar 26, 2021
  48. lilinchao@oschina.cnMar 31, 2021

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.