Re: 10% drop in code line count in PG 17

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: 10% drop in code line count in PG 17
Date: 2025-11-19 21:22:37
Message-ID: 1652873.1763587357@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Wed, Nov 19, 2025 at 03:21:33PM -0500, Tom Lane wrote:
>> Also ... are you in fact counting only what is in git? Because
>> I get different answers:

> No, I just followed the shell comment I wrote above the 'find' command
> shown above:

> # This script is used to compute the total number of "C" lines in the
> # release This should be run from the top of the Git tree after a 'make
> # distclean'

> And that tree has been built many times. Should I change my procedure?

Does "git status --ignored" show any leftover junk files?

I've found that "make distclean" isn't 100% reliable if you aren't
religious about doing it before every git pull or other change of
git HEAD. The pull might bring in new makefiles with a different
idea of what needs to be cleaned. For .c files I'd kind of expect
leftovers to be obvious because they won't get hidden by .gitignore
rules, but maybe you hit some case where they're still hidden.

I've largely migrated to using "git clean -dfxq", which has about
the same results in modern branches, but is faster and never (IME)
misses anything.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-11-19 21:30:07 Re: PRI?64 vs Visual Studio (2022)
Previous Message Petros Angelatos 2025-11-19 21:14:21 Unexpected flood or keepalive messages during logical replication