From: lilinchao@oschina.cn Date: Fri, 26 Mar 2021 03:34:36 GMT Subject: Re: Re: [PATCH v7] builtin/clone.c: add --reject-shallow option Message-ID: <33a250a28de411eb9ccd0024e87935e7@oschina.cn> In-Reply-To: <19c9dc128da911ebacc7d4ae5278bc1233465@pobox.com> -------------- lilinchao@oschina.cn >"Li Linchao via GitGitGadget" writes: > >> ... >> This patch offers a new option '--reject-shallow' that can reject to >> clone a shallow repository. >> >> Signed-off-by: lilinchao >> >> Reviewed-by: Derrick Stolee >> Reviewed-by: Junio C Hamano >> Reviewed-by: Johannes Schindelin >> Reviewed-by: Jonathan Tan > >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.