On Tue, Nov 18, 2025 at 10:25:38AM +0800, Chao Li wrote:
> I just reviewed the patch. Looks to me the correct three-commit split:
Committed, thanks for reviewing.
--
nathan
Hi Nathan,
I just reviewed the patch. Looks to me the correct three-commit split:
0001 updates tooling/configure so that 0002 will not introduce formatting
violation
0002 makes large formatting rewrite (tab->white spaces), and so that the commit
needs to be added to .git-blace-ignore-revs
0003
Nathan Bossart writes:
> Here is a rebased patch set. Notably, I've split it into three pieces.
> I'm planning to add 0002 to .git-blame-ignore-revs, as testing indicates
> this preserves the blame history reasonably well.
Good idea.
regards, tom lane
Here is a rebased patch set. Notably, I've split it into three pieces.
I'm planning to add 0002 to .git-blame-ignore-revs, as testing indicates
this preserves the blame history reasonably well.
--
nathan
>From 5d88f5b026dfe764d4e401297025ea865ae18bc5 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
On Fri, Nov 14, 2025 at 04:34:08PM -0500, Tom Lane wrote:
> Works for me. Do we need any special .gitattributes for the file
> at all, if we're relying on the TAP test to catch this?
We'd at least need -whitespace (I think), but I figured we might as well
highlight beginning-of-line tabs and trai
Nathan Bossart writes:
> I don't see a way in .gitattributes to check for _any_ tabs in a file, just
> for beginning-of-line indentation with tabs. But it's easy enough to add a
> check in the TAP test.
Works for me. Do we need any special .gitattributes for the file
at all, if we're relying on
On Fri, Nov 14, 2025 at 03:25:15PM -0500, Tom Lane wrote:
> I seem to recall a proposal that the best fix is to not use tabs
> at all in postgresql.conf.sample. That seems like a good way out
> to me. I think we could fix .gitattributes so that "git diff --check"
> would verify no tabs, but I've
Nathan Bossart writes:
> I noticed that GitHub is using 4-space tabs for this file [0], presumably
> due to this [1] recent change. I'm not aware of an official policy for
> this file, but it seems to be written for 8-space tabs.
> One way to fix this is to set our default tab width to 8 in
> .g
I noticed that GitHub is using 4-space tabs for this file [0], presumably
due to this [1] recent change. I'm not aware of an official policy for
this file, but it seems to be written for 8-space tabs.
One way to fix this is to set our default tab width to 8 in
.gitattributes/.editorconfig (see at
