Re: Commitfest problems

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Dec 14, 2014 at 2:24 PM, Mark Cave-Ayland
> <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk> wrote:
>> However if it were posted as part of patchset with a subject of "[PATCH]
>> gram.y: add EXCLUDED pseudo-alias to bison grammar" then this may pique
>> my interest enough to review the changes to the grammar rules, with the
>> barrier for entry reduced to understanding just the PostgreSQL-specific
>> parts.

> Meh. Such a patch couldn't possibly compile or work without modifying
> other parts of the tree. And I'm emphatically opposed to splitting a
> commit that would have taken the tree from one working state to
> another working state into a series of patches that would have taken
> it from a working state through various non-working states and
> eventually another working state.

Yeah; that would totally destroy the use of git bisect, which was supposed
to be an advantage of smaller patches.

Perhaps you could always design the patch split-up in such a way that
each incremental step still compiles, but that would greatly limit how
you could factorize the patch, so I'm not sure it comes out as a win.
If we're going to submit patches in small chunks I'd rather the chunks
are built around separation of concerns, and not held to "would this
compile in isolation?".

IOW, submission in chunks is one thing but it shouldn't necessarily
translate to committing in the same chunks.

regards, tom lane