Re: branching for 9.2devel
От | Aidan Van Dyk |
---|---|
Тема | Re: branching for 9.2devel |
Дата | |
Msg-id | BANLkTi=0b3-ETNajCo3xyT_q+V39SYRHPA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: branching for 9.2devel (Christopher Browne <cbbrowne@gmail.com>) |
Ответы |
Re: branching for 9.2devel
|
Список | 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.
В списке pgsql-hackers по дате отправления: