Re: branching for 9.2devel
Aidan Van Dyk <aidan@highrise.ca>
From: Aidan Van Dyk <aidan@highrise.ca>
To: Christopher Browne <cbbrowne@gmail.com>
Cc: Greg Stark <gsstark@mit.edu>, pgsql-hackers@postgresql.org
Date: 2011-04-25T15:49:40Z
Lists: pgsql-hackers
On Mon, Apr 25, 2011 at 11:32 AM, Christopher Browne <cbbrowne@gmail.com> wrote: > Methinks there'd need to be an experiment run where pgindent is run > each time on some sort of "parallel tree" for a little while, to let > people get some feel for what changes it introduces. The point is that if the tools worked "everywhere", "the same", then it it should be run *before* the commit is finalized (git has a hundred+1 ways to get this to happen, be creative). So if you ever ran it on a $COMMIT from the published tree, it would never do anything. From the sounds of it though, it's not quite ready for that. > Unfortunately, I'd fully expect there to be some interference between patches. > > Your patch changes the indentation of the code a little, breaking the > patch I wanted to submit just a little later. And, by the way, I had > already submitted my patch. So you broke my patch, even though mine > was contributed first. But if the only thing changed was the indentation level (because $PATCH2 wrapped a section of code your $PATCH1 changes completely in a new block, or removed a block level), git tools are pretty good at handling that. So, if everything is *always* pgindent clean, that means your new patch is too, and the only conflicting white-space-only change would be a complete block-level indentation (easily handled). And you still have those block-level indentation changes even if not using pgindent. Of course, that all depends on: 1) pgindent being "work everywhere", "exactly the same" 2) Discipline of all new published commits being "pgindent clean". a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.