On Wed, Sep 25, 2024 at 6:36 AM Michael Paquier <mich...@paquier.xyz> wrote:
> On Wed, Sep 25, 2024 at 06:19:39AM +0530, Tony Wayne wrote: > > These changes are for core ,I think it would be better to either move > whole > > changes to core or contrib as an extension. > > Please avoid top-posting. The community mailing lists use > bottom-posting, to ease discussions. See: > https://en.wikipedia.org/wiki/Posting_style#Bottom-posting > > Thanks for the feedback. > > On Wed, Sep 25, 2024 at 6:09 AM David G. Johnston < > > david.g.johns...@gmail.com> wrote: > >> Usually you'd want to use format-patch so your commit message(s) make it > >> into the artifact. Especially for something complex/large. > > The community wiki has some guidelines about all that: > https://wiki.postgresql.org/wiki/Submitting_a_Patch > > In my experience, it is much easier to sell a feature to the community > if a patch is organized into independent useful pieces with > refactoring pieces presented on top of the actual feature. In order > to achieve that `git format-patch` is essential because it is possible > to present a patch set organizing your ideas so as others need to > spend less time trying to figure out what a patch set is doing when > doing a review. format-patch with `git am` is also quite good to > track the addition of new files or the removal of old files. Writing > your ideas in the commit logs can also bring a lot of insight for > anybody reading your patches. > > For simpler and localized changes, using something like git diff would > be also OK that can be applied with a simple `patch` command can also > be fine. I've done plenty of work with patches sent to the lists this > way for bug fixes. Of course this is case-by-case, for rather complex > bug fixes format-patch can still be a huge gain of time when reading > somebody else's ideas on a specific matter. > -- > Michael > Thanks, I got it 👍.
