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.