On Mon, Dec 29, 2014 at 10:22 PM, Stefan Beller <sbel...@google.com> wrote: > Hi, > > so I have been sending commits to the git mailing list occasionally > for quite some time. In the last couple of weeks I send more and more > patches to the mailing list as it's part of my job now. Here is a > collection of practices I am following (or want to follow) and they > seem to be effective. > > Most of this is already documented in various documents in Documentation/* > and this email is no news for the regular contributors. It may help new comers > though. > > * Split patches up into logical pieces as you go. > > It's easy to go wild and after hours of hacking you have implemented a cool > new > feature. This the natural flow of hacking as it's the most fun. But > this approach > is not easy to be reviewed. So let me explain how reviewing works in > the git project. > > Reviewing works in the git project is quite liberal, anybody > is encouraged to > comment on patches flying by. Junio, the maintainer then > decides which patches > he picks up and merges them into the various stages of git > (pu, next, master, maint). > The decision which patches are worth for inclusion is based on > the amount of discussion > by the community and generally a patch only makes it if a > concensus is met. > > * git send-email is the only email client I trust for sending patches > IMO, sending email is the easiest part.
The hard begins when you have to edit your patch and resend with the reviewers' feedback incorporated. For me that is the most tricky and hard part to get right, specially when using GMail as an email client. How do you handle that part of the process? -- Thiago Farina -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
