Jelte Fennema <postgres@jeltef.nl> writes:
> Sounds like this conflict could be handled fairly easily by
> having a local git hook rerunning pgindent whenever
> you rebase a commit:
> 1. if you changed typedefs.list the hook would format all files
> 2. if you didn't it only formats the files that you changed
I think that would be undesirable, because then reindentation noise
in completely-unrelated files would get baked into feature commits,
complicating review and messing up "git blame" history.
The approach we currently have allows reindent effects to be
separated into ignorable labeled commits, which is a nice property.
> Merge failures are one issue. But personally the main benefit that
> I would be getting is being able to run pgindent on the files
> I'm editing and get this weird +12 columns formatting correct
> without having to manually type it. Without pgindent also
> changing random parts of the files that someone else touched
> a few commits before me.
Yeah, that always annoys me too, but I've always considered that
it's my problem not something I can externalize onto other people.
The real bottom line here is that AFAICT, there are fewer committers
who care about indent cleanliness than committers who do not, so
I do not think that the former group get to impose strict rules
on the latter, much as I might wish otherwise.
FWIW, Andrew's recent --show-diff feature for pgindent has
already improved my workflow for that. I can do
"pgindent --show-diff >fixindent.patch", manually remove any hunks
in fixindent.patch that don't pertain to the code I'm working on,
and apply what remains to fix up my new code. (I had been doing
something basically like this, but with more file-copying steps
to undo pgindent's edit-in-place behavior.)
regards, tom lane
