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

["lilinchao@oschina.cn" <lilinchao@oschina.cn>]

--------------
lilinchao@oschina.cn
>"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.