On Thu, Aug 13, 2020 at 01:01:42PM -0400, Derrick Stolee wrote: > On 8/13/2020 10:59 AM, Jeff King wrote: > > There's no reason that bugreport has to be a separate binary. And since > > it links against libgit.a, it has a rather large disk footprint. Let's > > make it a builtin, which reduces the size of a stripped installation > > from 24MB to 22MB. > > > > This also simplifies our Makefile a bit. And we can take advantage of > > builtin niceties like RUN_SETUP_GENTLY. > > I agree that this is a good change. I'm a bit surprised that a > feature added so recently wasn't added as a builtin in the first > place. Perhaps that was a conscious decision? Maybe it was just > because there was some point in time where it might have been > relegated to contrib. I looked in the history for any rationale, but couldn't find any. There is some discussion in the list, though. It looks like we moved from a builtin to standalone between v3 and v4 of the series, due to this sub-thread: https://lore.kernel.org/git/xmqqr2284is5.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/ My take is: - I agree with Johannes that in terms of resource usage, builtins are better. I'm skeptical that extra code within the Git binary produces a meaningful impact on running other builtins (but I'd be happy to look at evidence if somebody has it). - Adding shared-library dependencies definitely _does_ impact other builtin commands. And I think last November when the series was shaping up that it wasn't clear if we might link to system-specific data gathering libraries. But that wasn't how the series shook out; we gather very little general system info, and we do it with basic and lightweight techniques (like uname, or compiler preprocessor macros). That could change eventually of course, but it's not like switching back to a stand-alone at that point is a big deal. -Peff
