Craig Ringer <craig@2ndquadrant.com> writes:
> 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.
TBH, I'm not really on board with this line of argument. I don't find
broken-down patches to be particularly useful for review purposes. An
example I was just fooling with this week is the GROUPING SETS patch,
which was broken into three sections for no good reason at all. (The
fourth and fifth subpatches, being alternative solutions to one problem,
are in a different category of course.) Too often, decisions made in
one subpatch don't make any sense until you see the larger picture.
Also, speaking of the larger picture: the current Postgres revision
history amounts to 37578 commits (as of sometime yesterday) --- and that's
just in the HEAD branch. If we'd made an effort to break feature patches
into bite-size chunks like you're recommending here, we'd probably have
easily half a million commits in the mainline history. That would not be
convenient to work with, and I really doubt that it would be more useful
for "git bisect" purposes, and I'll bet a large amount of money that most
of them would not have had commit messages composed with any care at all.
regards, tom lane
