Jeff King wrote: > On Thu, Jun 24, 2021 at 03:16:48PM +0200, Ævar Arnfjörð Bjarmason wrote: > > > This is probably all stuff that's been on list-before / known by > > some/all people in the CC list, but in case not: I looked a bit into why > > we'e so frequently re-linking and re compiling things these days, > > slowing down e.g. "git rebase --exec='make ...'". > > > > These are all fixable issues, I haven't worked on them, just some notes > > in case anyone has better ideas: > > From a quick skim I didn't see anything wrong in your analysis or > suggestions. I do kind of wonder if we are hitting a point of > diminishing returns here. "make -j16" on my system takes ~175ms for a > noop, and ~650ms if I have to regenerate version.h (it's something like > 2s total of CPU, but I have 8 cores). > > I know I've probably got a nicer machine than many other folks. But at > some point correctness and avoiding complexity in the Makefile become a > win over shaving off a second from compile times. You'd probably find > lower hanging fruit in the test suite which could shave off tens of > seconds. :) That's not a good enough reason to not try to improve something. In fact, it's a known fallacy called the fallacy of relative privation [1]. Also, your definition of "correctness" is not necessarily shared by everyone. I for one don't see what I'm gaining by running tests with GIT_VERSION = 2.32.0.97.g949e814b27, and then 2.32.0.98.gcfb60a24d6. What's wrong with GIT_VERSION = 2.33-dev? Sure, I understand that some people might want to have a precise version, but when I'm doing development I don't. Perhaps set a static version when DEVELOPER=1? [1] https://rationalwiki.org/wiki/Not_as_bad_as -- Felipe Contreras
