-------------- lilinchao@xxxxxxxxxx >"Li Linchao via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> ... >> This patch offers a new option '--reject-shallow' that can reject to >> clone a shallow repository. >> >> Signed-off-by: lilinchao <lilinchao@xxxxxxxxxx> >> >> Reviewed-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx> >> Reviewed-by: Junio C Hamano<gitster@xxxxxxxxx> >> Reviewed-by: Johannes Schindelin <johannes.schindelin@xxxxxx> >> Reviewed-by: Jonathan Tan<jonathantanmy@xxxxxxxxxx> > >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.
