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.
