Re: 10% drop in code line count in PG 17
| От | Bruce Momjian |
|---|---|
| Тема | Re: 10% drop in code line count in PG 17 |
| Дата | |
| Msg-id | aR49d9ejHV5DwfiN@momjian.us обсуждение исходный текст |
| Ответ на | Re: 10% drop in code line count in PG 17 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: 10% drop in code line count in PG 17
|
| Список | pgsql-hackers |
On Wed, Nov 19, 2025 at 04:22:37PM -0500, Tom Lane wrote: > 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. I think you are right. Attached is the difference between the output for 16 & 17. Let me do some more research and run all the versions again and report back, thanks. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
Вложения
В списке pgsql-hackers по дате отправления: