On Mon, Apr 25, 2011 at 11:32 AM, Christopher Browne <cbbro...@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, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
