Re: Re: [PATCH v7] builtin/clone.c: add --reject-shallow option
- From
- lilinchao@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.