Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Robert Haas wrote:
> What is a bit frustrating to me is that a number of Tom's changes to
> the first two patches were trivial whitespace changes that required me
> to rebase for no obvious reason.   Either those changes were made
> accidentally as Tom was fooling around with what I had done, or they
> were made because Tom had some reason to believe that they would play
> more nicely with pgindent, though what those reasons may have been is
> entirely opaque to me.
> 
> I think that it is good for us as a community to talk about the
> reasons why Tom changes patches.  If some of them are bad reasons,
> maybe talking about it will persuade him to stop.  If they are good
> reasons, perhaps the rest of us can learn from them.  But I think it
> behooves us to talk about specific problems rather than engage in
> open-ended griping.  I haven't been a member of this community for a
> super-long time, but already I can see that there is a correlation
> between who wrote the patch and how heavily it gets edited on commit.

Sometimes I clean up code style in patches because I don't know there
are other patches depending on it;  if I knew there were, I would be
less likely to change patched code, but it is hard to remember which
patches have others pending and which don't.  Perhaps being explicit
might help remind patch appliers.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +