Hi Junio, On Thu, 13 Aug 2020, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > 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. > > > > Signed-off-by: Jeff King <peff@xxxxxxxx> > > --- > > Makefile | 6 +----- > > builtin.h | 1 + > > bugreport.c => builtin/bugreport.c | 10 +++------- > > contrib/buildsystems/CMakeLists.txt | 5 +---- > > git.c | 1 + > > 5 files changed, 7 insertions(+), 16 deletions(-) > > rename bugreport.c => builtin/bugreport.c (96%) > > I am on the fence, as bugreport does not seem to be fully completed > part of the system. The original thinking was that it may soon want > to grow by linking with platform specific libraries for lower-level > system characteristic identification, at which time we'd not want to > have it in builtins and "we can take advantage of builtin niceties" > will cause us regrets. The only reason that hasn't happened as far > as I can see is because its development speed is rather slow. No, I think the reason is much more benign: my suggestion to query information from the respective executables that _already_ link to said shared libraries seems to have born fruit. It has the additional advantage that we need not worry about cases where `git-bugreport` would look at a different dependency than, say, `git-remote--curl`. So yes, I am rather delighted that `bugreport` finally takes this direction. It makes me much less worried about the reliability of the information provided in bug reports. Ciao, Dscho
