Re: 10% drop in code line count in PG 17 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 10% drop in code line count in PG 17
Date
Msg-id 1652873.1763587357@sss.pgh.pa.us
Whole thread Raw
In response to Re: 10% drop in code line count in PG 17  (Bruce Momjian <bruce@momjian.us>)
Responses Re: 10% drop in code line count in PG 17
Re: 10% drop in code line count in PG 17
List pgsql-hackers
Bruce Momjian <bruce@momjian.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



pgsql-hackers by date:

Previous
From: Petros Angelatos
Date:
Subject: Unexpected flood or keepalive messages during logical replication
Next
From: Tom Lane
Date:
Subject: Re: PRI?64 vs Visual Studio (2022)