On 14/12/14 15:51, Craig Ringer wrote: > On 12/14/2014 10:35 PM, Mark Cave-Ayland wrote: >> Compare this to say, for example, huge patches such as RLS. > > I specifically objected to that being flattened into a single monster > patch when I saw that'd been done. If you look at my part in the work on > the row security patch, while I was ultimately unsuccessful in getting > the patch mergeable I spent quite a bit of time splitting it up into a > logical patch-series for sane review and development. I am quite annoyed > that it was simply flattened back into an unreviewable, hard-to-follow > blob and committed in that form. > > It's not like development on a patch series is difficult. You commit > small fixes and changes, then you 'git rebase -i' and reorder them to > apply to the appropriate changesets. Or you can do a 'rebase -i' and in > 'e'dit mode make amendments to individual commits. Or you can commit > 'fixup!'s that get auto-squashed. > > This is part of my grumbling about the use of git like it's still CVS.
I just want to add that I'm always grateful for the time that yourself and all committers put into PostgreSQL, and my example of RLS was really to signify "big feature X" rather than to pick on a particular aspect of that patch. I apologise if you though I was in any way criticising the work that you, or anyone else, put into this feature. The argument I wanted to make is that if someone starts seeing a problem with a current build of PostgreSQL and git bisects it down to a particular commit, then smaller, iterative commits are extremely helpful in this regard. When searching for a needle in a haystack, there is very big difference between a "add big feature X" haystack and a "change struct alignment for Y" haystack, the latter which is implicit in having smaller, iterative patchsets. ATB, Mark. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers